Engine Atlas

MySQL 잠금 읽기: SELECT ... FOR UPDATE와 Next-Key Lock

locking read · next-key interval · data_locks

MySQL 8.4.10captured evidence

English

학습 안내

이 Lab에서 답할 질문

같은 tenant_id range에서 plain SELECT와 FOR UPDATE, 그리고 isolation level이 Session B INSERT와 Session C UPDATE의 wait를 어떻게 바꾸나요?

실행 엔진: MySQL 8.4.10

누가 실행하나요?

Session A가 range를 읽고 lock을 유지하며, Session B는 priority 25 INSERT, Session C는 job_id 103 UPDATE를 시도하고 Session O가 COMMIT 후 결과를 봅니다.

무엇을 고정하나요?

jobs table, idx_tenant_priority_job, tenant_id = 7 range와 job_id 102·103 결과 rows를 고정합니다.

실행 SQL

SELECT job_id, priority, revision, note
FROM lock_jobs FORCE INDEX (idx_tenant_priority_job)
WHERE tenant_id = 7
  AND priority >= 20
  AND priority < 40
ORDER BY priority, job_id
FOR UPDATE

무엇이 달라지나요?

Session A가 보유한 record·gap·next-key lock과 B → A, C → A wait edge가 variant별로 달라집니다.

무엇이 그대로인가요?

range predicate, holder result rows, B와 C의 시도, Session A COMMIT 뒤 최종 완료 순서는 동일합니다.

먼저 예측해 보세요

REPEATABLE READ + SELECT ... FOR UPDATE에서 COMMIT 전 누가 기다릴까요?

plain SELECT와 같으므로 아무도 기다리지 않는다.Session C의 UPDATE만 Session A를 기다린다.Session C의 row UPDATE와 Session B의 gap INSERT가 모두 Session A를 기다린다.

증거 미션

RR · FOR UPDATE variant의 wait graph 단계를 열어 Session A COMMIT 전에 누가 무엇을 기다리는지 확인하세요.

어디를 보나요?: Trace corridor의 wait edge에서 각 edge의 indexName, lockMode, lockData를 함께 읽습니다.
이동할 화면: RR · FOR UPDATE · wait graph

무엇이 보여야 하나요?

확인할 관찰

이 variant에는 wait edge가 두 개 있습니다. Session C의 job_id 103 UPDATE는 PRIMARY row lock을 기다리고, Session B의 priority 25 INSERT는 idx_tenant_priority_job의 LOCK_DATA (7, 30, 103) 앞 gap을 기다립니다. 둘 다 Session A COMMIT 전 상태입니다.

근거 경계

Captured: data_lock_waits의 C → A와 B → A wait edge와 lock 속성

Checkpoint · evidence로 설명하기세 variant의 captured wait edge는 어떻게 다르나요?답과 근거 확인

rr-plain은 wait edge가 없고, rr-for-update는 C → A와 B → A가 함께 있으며, rc-for-update는 C → A row wait만 남습니다. Session A COMMIT 뒤 waiting statement가 완료됩니다.

근거 경계

Captured: data_lock_waits의 variant별 wait edge

이번 Lab의 핵심

locking read는 반환 rows뿐 아니라 index record와 그 앞 gap을 보호할 수 있으며, isolation level이 INSERT를 막는 range protection을 바꿉니다.

다음 연결

이 Lab은 access path에서 시작해 row version과 lock wait까지 이어진 8개 Lab 경로의 끝입니다. 이전 Lab의 consistent read와 나란히 비교해 마무리하세요.

용어 확인

record lock처음 다루는 Lab 08: index의 특정 record에 설정되어 충돌하는 UPDATE나 locking read를 기다리게 하는 lock입니다.
gap lock처음 다루는 Lab 08: index record 사이의 간격을 보호해 그 범위에 들어오는 INSERT와 충돌할 수 있는 lock입니다.
next-key lock처음 다루는 Lab 08: index record lock과 그 record 앞의 gap lock을 결합해 range를 보호하는 InnoDB lock 형태입니다.
lock wait처음 다루는 Lab 08: 요청한 lock이 다른 transaction의 호환되지 않는 lock과 충돌해 해제될 때까지 statement가 멈춘 상태입니다.
READ COMMITTED처음 다루는 Lab 07: 각 consistent read가 statement 시작 시점의 새 snapshot을 사용하는 isolation level입니다.

이 쿼리는 뭘 하나요?

tenant_id = 7이고 priority가 20 이상 40 미만인 task row를 조회합니다.

조회 결과job_id 102, 103

Session A가 조회한 row와 그 사이 index gap을 잠그기 때문에 job_id 103 UPDATE와 job_id 106 INSERT가 모두 COMMIT까지 기다립니다.

같은 SELECT를 세 조건으로 실행해서 Session B의 INSERT와 Session C의 UPDATE가 바로 실행되는지, COMMIT을 기다리는지 비교합니다.

현재 비교 조건: REPEATABLE READ + SELECT ... FOR UPDATE
Session A: Session A · SELECT 실행
Session B: Session B · INSERT 시도
Session C: Session C · UPDATE 시도

Session A가 SELECT하기 전

WHERE 절은 lock_jobs에서 tenant_id = 7인 row만 보고, 그중 priority가 20 이상 40 미만인 row를 고릅니다.

조회 범위

tenant_id	priority	job_id
7	10	101
7	20	102
7	30	103
7	40	104
7	50	105

tenant_id = 7 · priority >= 20 · priority < 40

Session A가 SELECT한 뒤

Session A는 job_id 102, 103을 읽고 FOR UPDATE lock을 유지합니다. Session C는 job_id 103 row lock에서, Session B는 priority 25를 넣을 index gap에서 기다립니다.

SELECT ... FOR UPDATE

job_id 102tenant_id 7 · priority 20
job_id 103tenant_id 7 · priority 30

Session C · UPDATE job_id 103

Session A COMMIT까지 대기

Session B · INSERT job_id 106, priority 25

Session A COMMIT까지 대기

Session A가 COMMIT한 뒤

Session A가 COMMIT하면 lock이 풀리고 기다리던 UPDATE와 INSERT가 이어서 완료됩니다.

UPDATED · job_id 103
INSERTED · job_id 106

tenant_id	priority	job_id	state
7	20	102	UNCHANGED
7	25	106	INSERTED
7	30	103	UPDATED

.locking-read-next-key-locks-page { overflow: auto !important; background: #f4f6f7; } .locking-read-next-key-locks-page main { height: auto !important; min-height: 100dvh; } .locklab-shell { display: none !important; } .locklab-noscript { width: min(100% - 32px, 96rem); margin: 0 auto; padding: 28px 0 72px; color: #171a1d; overflow-wrap: anywhere; } .locklab-noscript > header { padding-bottom: 24px; border-bottom: 1px solid #d8dde1; } .locklab-noscript > section, .locklab-noscript > nav { padding-block: 24px; border-bottom: 1px solid #d8dde1; } .locklab-noscript h1 { margin: 8px 0 12px; font-size: 32px; line-height: 1.25; letter-spacing: 0; } .locklab-noscript h2 { margin: 0 0 14px; font-size: 22px; letter-spacing: 0; } .locklab-noscript h3 { margin: 22px 0 10px; font-size: 18px; letter-spacing: 0; } .locklab-noscript h4 { margin: 0 0 8px; font-size: 16px; letter-spacing: 0; } .locklab-noscript p, .locklab-noscript li, .locklab-noscript dt, .locklab-noscript dd, .locklab-noscript td, .locklab-noscript th { font-size: 15px; line-height: 1.6; } .locklab-noscript a { color: #174ca7; } .locklab-noscript-eyebrow { margin: 0; color: #0d6d4d; font-weight: 800; } .locklab-noscript-nav { display: flex; flex-wrap: wrap; align-items: center; gap: 10px 20px; } .locklab-noscript-nav strong { margin-right: auto; } .locklab-noscript-code { max-width: 100%; margin: 10px 0; padding: 16px; overflow-x: auto; border: 1px solid #d8dde1; background: #fff; font: 15px/1.65 "SFMono-Regular", Consolas, monospace; white-space: pre-wrap; } .locklab-noscript-grid { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 1px; margin: 12px 0; padding: 1px; background: #d8dde1; } .locklab-noscript-grid > div { min-width: 0; padding: 14px; background: #fff; } .locklab-noscript-scroll { max-width: 100%; overflow-x: auto; } .locklab-noscript table { width: 100%; min-width: 760px; border-collapse: collapse; background: #fff; } .locklab-noscript th, .locklab-noscript td { padding: 8px 10px; border: 1px solid #d8dde1; text-align: left; vertical-align: top; } .locklab-noscript th { background: #f2f5f6; } .locklab-noscript code { overflow-wrap: anywhere; } .locklab-noscript-variant { padding: 18px 0 30px; border-bottom: 1px solid #edf0f2; } .locklab-noscript-variant:last-child { border-bottom: 0; } .locklab-noscript-steps { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 1px; margin: 0; padding: 1px; background: #d8dde1; list-style-position: inside; } .locklab-noscript-steps > li { min-width: 0; padding: 14px; background: #fff; } .locklab-noscript-steps p { color: #46525a; } .locklab-noscript-result { background: #edf4ff; } @media (max-width: 760px) { .locklab-noscript { width: min(100% - 24px, 96rem); } .locklab-noscript h1 { font-size: 26px; } .locklab-noscript-grid, .locklab-noscript-steps { grid-template-columns: minmax(0, 1fr); } }

Captured · MySQL 8.4.10 · arm64

MySQL 잠금 읽기: SELECT ... FOR UPDATE와 Next-Key Lock

같은 range query가 isolation level과 FOR UPDATE 여부에 따라 UPDATE와 INSERT를 어디서 기다리게 하는지 실제 MySQL 8.4.10 lock evidence로 추적합니다.

English

Fixture와 index 정의

DROP DATABASE IF EXISTS engine_atlas_locking_read;
CREATE DATABASE engine_atlas_locking_read
  CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

USE engine_atlas_locking_read;

CREATE TABLE lock_jobs (
  job_id INT UNSIGNED NOT NULL,
  tenant_id INT UNSIGNED NOT NULL,
  priority INT UNSIGNED NOT NULL,
  revision TINYINT UNSIGNED NOT NULL,
  note VARCHAR(32) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
  PRIMARY KEY (job_id),
  KEY idx_tenant_priority_job (tenant_id, priority, job_id)
) ENGINE=InnoDB
  ROW_FORMAT=DYNAMIC
  STATS_PERSISTENT=1;

INSERT INTO lock_jobs VALUES
  (101, 7, 10, 1, 'seed-101'),
  (102, 7, 20, 1, 'seed-102'),
  (103, 7, 30, 1, 'seed-103'),
  (104, 7, 40, 1, 'seed-104'),
  (105, 7, 50, 1, 'seed-105'),
  (201, 8, 25, 1, 'other-201');

ANALYZE TABLE lock_jobs;

tenant_id	priority	job_id	state
7	10	101	seed
7	20	102	seed
7	25	106	attempted-insert
7	30	103	seed
7	40	104	seed
7	50	105	seed

실행 SQL

plain SELECT

SELECT job_id, priority, revision, note
FROM lock_jobs FORCE INDEX (idx_tenant_priority_job)
WHERE tenant_id = 7
  AND priority >= 20
  AND priority < 40
ORDER BY priority, job_id

SELECT ... FOR UPDATE

SELECT job_id, priority, revision, note
FROM lock_jobs FORCE INDEX (idx_tenant_priority_job)
WHERE tenant_id = 7
  AND priority >= 20
  AND priority < 40
ORDER BY priority, job_id
FOR UPDATE

Session C · UPDATE

UPDATE lock_jobs
SET revision = 2,
    note = 'updated-by-c'
WHERE job_id = 103

Session B · INSERT

INSERT INTO lock_jobs
VALUES (106, 7, 25, 1, 'inserted-by-b')

Native plan

REPEATABLE READ + SELECT

access type: range
selected key: idx_tenant_priority_job
estimated cost: 0.71
estimated rows: 1
actual time: 0.0734..0.0791 ms
actual rows: 2 · loops 1

-> Index range scan on lock_jobs using idx_tenant_priority_job over (tenant_id = 7 AND 20 <= priority < 40), with index condition: ((lock_jobs.tenant_id = 7) and (lock_jobs.priority >= 20) and (lock_jobs.priority < 40))  (cost=0.71 rows=1)

REPEATABLE READ + SELECT ... FOR UPDATE

access type: range
selected key: idx_tenant_priority_job
estimated cost: 0.71
estimated rows: 1
actual time: 0.0293..0.0333 ms
actual rows: 2 · loops 1

-> Index range scan on lock_jobs using idx_tenant_priority_job over (tenant_id = 7 AND 20 <= priority < 40), with index condition: ((lock_jobs.tenant_id = 7) and (lock_jobs.priority >= 20) and (lock_jobs.priority < 40))  (cost=0.71 rows=1)

READ COMMITTED + SELECT ... FOR UPDATE

access type: range
selected key: idx_tenant_priority_job
estimated cost: 0.71
estimated rows: 1
actual time: 0.0307..0.0366 ms
actual rows: 2 · loops 1

-> Index range scan on lock_jobs using idx_tenant_priority_job over (tenant_id = 7 AND 20 <= priority < 40), with index condition: ((lock_jobs.tenant_id = 7) and (lock_jobs.priority >= 20) and (lock_jobs.priority < 40))  (cost=0.71 rows=1)

Captured locks와 waits

REPEATABLE READ + SELECT

REPEATABLE READ · 0 lock rows · 0 wait edges

session	object	index	lock mode	status	lock_data
captured row 없음

requester	blocker	index	lock mode	lock_data
captured row 없음

REPEATABLE READ + SELECT ... FOR UPDATE

REPEATABLE READ · 10 lock rows · 2 wait edges

session	object	index	lock mode	status	lock_data
A	lock_jobs	`idx_tenant_priority_job`	`X`	GRANTED	`7, 20, 102`
A	lock_jobs	`idx_tenant_priority_job`	`X`	GRANTED	`7, 30, 103`
A	lock_jobs	`idx_tenant_priority_job`	`X`	GRANTED	`7, 40, 104`
A	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	GRANTED	`102`
A	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	GRANTED	`103`
A	lock_jobs	`TABLE`	`IX`	GRANTED	`NULL`
C	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	WAITING	`103`
C	lock_jobs	`TABLE`	`IX`	GRANTED	`NULL`
B	lock_jobs	`idx_tenant_priority_job`	`X,GAP,INSERT_INTENTION`	WAITING	`7, 30, 103`
B	lock_jobs	`TABLE`	`IX`	GRANTED	`NULL`

requester	blocker	index	lock mode	lock_data
Session C	Session A	`PRIMARY`	`X,REC_NOT_GAP`	`103`
Session B	Session A	`idx_tenant_priority_job`	`X,GAP,INSERT_INTENTION`	`7, 30, 103`

READ COMMITTED + SELECT ... FOR UPDATE

READ COMMITTED · 7 lock rows · 1 wait edges

session	object	index	lock mode	status	lock_data
A	lock_jobs	`idx_tenant_priority_job`	`X,REC_NOT_GAP`	GRANTED	`7, 20, 102`
A	lock_jobs	`idx_tenant_priority_job`	`X,REC_NOT_GAP`	GRANTED	`7, 30, 103`
A	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	GRANTED	`102`
A	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	GRANTED	`103`
A	lock_jobs	`TABLE`	`IX`	GRANTED	`NULL`
C	lock_jobs	`PRIMARY`	`X,REC_NOT_GAP`	WAITING	`103`
C	lock_jobs	`TABLE`	`IX`	GRANTED	`NULL`

requester	blocker	index	lock mode	lock_data
Session C	Session A	`PRIMARY`	`X,REC_NOT_GAP`	`103`

A COMMIT 전후 결과

REPEATABLE READ + SELECT

session	A COMMIT 전	A COMMIT 후	affected rows
Session C	completed-before-holder-commit	completed-before-holder-commit	1
Session B	completed-before-holder-commit	completed-before-holder-commit	1

REPEATABLE READ + SELECT ... FOR UPDATE

session	A COMMIT 전	A COMMIT 후	affected rows
Session C	waiting-on-holder	completed-after-holder-commit	1
Session B	waiting-on-holder	completed-after-holder-commit	1

READ COMMITTED + SELECT ... FOR UPDATE

session	A COMMIT 전	A COMMIT 후	affected rows
Session C	waiting-on-holder	completed-after-holder-commit	1
Session B	completed-before-holder-commit	completed-before-holder-commit	1

Fresh observer result

job_id	priority	revision	note
102	20	1	`seed-102`
106	25	1	`inserted-by-b`
103	30	2	`updated-by-c`

전체 설명

REPEATABLE READ + SELECT

읽은 row에 쓰기 lock을 잡지 않아 UPDATE와 INSERT가 바로 실행됩니다.

01 · Schema · Secondary index가 저장하는 정확한 tuple

idx_tenant_priority_job는 (tenant_id, priority, job_id) 순서로 정렬됩니다. job_id 101~105는 tenant_id 7의 seed row이고, job_id 201은 다른 tenant의 row입니다.
barrier.connections-ready
02 · Predicate · WHERE 절이 여는 [20, 40) 범위

tenant_id = 7, priority >= 20, priority < 40이 (7,20,102)와 (7,30,103)을 결과로 고릅니다. (7,40,104)는 반환되지 않는 upper range boundary입니다.
barrier.holder-read-complete
03 · EXPLAIN ANALYZE · range access와 실제 2 rows

MySQL 8.4.10은 idx_tenant_priority_job의 range access를 선택했습니다. native plan의 estimate는 rows=1, cost=0.71이고 EXPLAIN ANALYZE에서는 actual rows=2, loops=1입니다.
barrier.plans-captured
04 · Session A · Holder transaction 시작

Session A가 선택한 isolation level에서 transaction을 시작합니다. rr-plain은 일반 SELECT이고, 나머지 두 variant는 같은 SQL 끝에 FOR UPDATE를 붙여 locking read를 실행합니다.
barrier.connections-ready
05 · Session A · A가 읽은 row는 102와 103

Session A의 결과는 job_id 102(priority 20)와 103(priority 30)입니다. ORDER BY priority, job_id 순서와 secondary index 순서가 일치합니다.
barrier.holder-read-complete
06 · data_locks · Secondary RECORD와 PRIMARY row lock

rr-for-update에서 Session A는 secondary tuple (7,20,102), (7,30,103), 경계 (7,40,104)에 X lock을 보유하고 PRIMARY 102와 103에는 X,REC_NOT_GAP lock을 보유합니다.
barrier.contention-captured
07 · Session C · UPDATE는 PRIMARY 103에서 충돌

Session C가 WHERE job_id = 103인 UPDATE를 실행합니다. locking read가 있으면 PRIMARY 103의 X,REC_NOT_GAP 요청이 Session A의 granted row lock과 충돌해 COMMIT 전까지 기다립니다.
barrier.update-outcome-established
08 · Session B · INSERT는 (7,25,106) 위치를 요청

Session B의 INSERT는 secondary index에서 (7,20,102)와 (7,30,103) 사이에 (7,25,106)을 넣으려 합니다. rr-for-update에서 INSERT INTENTION은 다음 tuple (7,30,103)의 gap lock과 충돌합니다.
barrier.insert-outcome-established
09 · Wait evidence · 실제 data_lock_waits로 확인한 blocker

rr-for-update에는 C → A의 PRIMARY 103 wait와 B → A의 idx_tenant_priority_job (7,30,103) wait가 함께 나타납니다. rc-for-update에는 C → A row wait만 남습니다.
barrier.contention-captured
10 · B-tree interval · Next-key lock이 보호하는 index interval

Captured B wait의 LOCK_DATA는 (7,30,103)입니다. Next-key model에서 attempted (7,25,106)은 이 record 앞 gap에 놓이므로 Session A의 COMMIT을 기다립니다.
barrier.contention-captured
11 · Clustered index · Secondary tuple에서 PRIMARY row로 이동

secondary leaf의 carried primary key 102와 103을 따라 clustered PRIMARY row를 찾습니다. Session C의 UPDATE는 job_id 103 row를 바꾸므로 A가 보유한 PRIMARY 103 lock과 직접 충돌합니다.
barrier.contention-captured
12 · Wait graph · Session C와 B가 Session A의 어떤 lock을 기다리는지 확인하기

rr-plain은 wait edge가 없습니다. rr-for-update는 Session C와 B가 모두 A를 기다리고, rc-for-update는 Session C만 A를 기다립니다. 각 edge는 실제 indexName, lockMode, lockData와 연결됩니다.
barrier.contention-captured
13 · COMMIT · A의 COMMIT 이후 대기 작업 재개

Session A가 COMMIT하면 보유 lock이 해제됩니다. 기다리던 UPDATE와 INSERT는 순서대로 완료되고 affected rows는 각각 1이며, deadlock은 발생하지 않습니다.
barrier.holder-commit-closed
14 · Session O · 새 transaction이 확인한 최종 3 rows

Session O의 새 read 결과는 job_id 102, 106, 103 순서입니다. INSERT된 priority 25 row가 사이에 들어오고 job_id 103은 revision 2, note updated-by-c로 보입니다.
barrier.final-observer-result

REPEATABLE READ + SELECT ... FOR UPDATE

job_id 103 UPDATE와 priority 25 INSERT가 모두 Session A의 COMMIT을 기다립니다.

01 · Schema · Secondary index가 저장하는 정확한 tuple

idx_tenant_priority_job는 (tenant_id, priority, job_id) 순서로 정렬됩니다. job_id 101~105는 tenant_id 7의 seed row이고, job_id 201은 다른 tenant의 row입니다.
barrier.connections-ready
02 · Predicate · WHERE 절이 여는 [20, 40) 범위

tenant_id = 7, priority >= 20, priority < 40이 (7,20,102)와 (7,30,103)을 결과로 고릅니다. (7,40,104)는 반환되지 않는 upper range boundary입니다.
barrier.holder-read-complete
03 · EXPLAIN ANALYZE · range access와 실제 2 rows

MySQL 8.4.10은 idx_tenant_priority_job의 range access를 선택했습니다. native plan의 estimate는 rows=1, cost=0.71이고 EXPLAIN ANALYZE에서는 actual rows=2, loops=1입니다.
barrier.plans-captured
04 · Session A · Holder transaction 시작

Session A가 선택한 isolation level에서 transaction을 시작합니다. rr-plain은 일반 SELECT이고, 나머지 두 variant는 같은 SQL 끝에 FOR UPDATE를 붙여 locking read를 실행합니다.
barrier.connections-ready
05 · Session A · A가 읽은 row는 102와 103

Session A의 결과는 job_id 102(priority 20)와 103(priority 30)입니다. ORDER BY priority, job_id 순서와 secondary index 순서가 일치합니다.
barrier.holder-read-complete
06 · data_locks · Secondary RECORD와 PRIMARY row lock

rr-for-update에서 Session A는 secondary tuple (7,20,102), (7,30,103), 경계 (7,40,104)에 X lock을 보유하고 PRIMARY 102와 103에는 X,REC_NOT_GAP lock을 보유합니다.
barrier.contention-captured
07 · Session C · UPDATE는 PRIMARY 103에서 충돌

Session C가 WHERE job_id = 103인 UPDATE를 실행합니다. locking read가 있으면 PRIMARY 103의 X,REC_NOT_GAP 요청이 Session A의 granted row lock과 충돌해 COMMIT 전까지 기다립니다.
barrier.update-outcome-established
08 · Session B · INSERT는 (7,25,106) 위치를 요청

Session B의 INSERT는 secondary index에서 (7,20,102)와 (7,30,103) 사이에 (7,25,106)을 넣으려 합니다. rr-for-update에서 INSERT INTENTION은 다음 tuple (7,30,103)의 gap lock과 충돌합니다.
barrier.insert-outcome-established
09 · Wait evidence · 실제 data_lock_waits로 확인한 blocker

rr-for-update에는 C → A의 PRIMARY 103 wait와 B → A의 idx_tenant_priority_job (7,30,103) wait가 함께 나타납니다. rc-for-update에는 C → A row wait만 남습니다.
barrier.contention-captured
10 · B-tree interval · Next-key lock이 보호하는 index interval

Captured B wait의 LOCK_DATA는 (7,30,103)입니다. Next-key model에서 attempted (7,25,106)은 이 record 앞 gap에 놓이므로 Session A의 COMMIT을 기다립니다.
barrier.contention-captured
11 · Clustered index · Secondary tuple에서 PRIMARY row로 이동

secondary leaf의 carried primary key 102와 103을 따라 clustered PRIMARY row를 찾습니다. Session C의 UPDATE는 job_id 103 row를 바꾸므로 A가 보유한 PRIMARY 103 lock과 직접 충돌합니다.
barrier.contention-captured
12 · Wait graph · Session C와 B가 Session A의 어떤 lock을 기다리는지 확인하기

rr-plain은 wait edge가 없습니다. rr-for-update는 Session C와 B가 모두 A를 기다리고, rc-for-update는 Session C만 A를 기다립니다. 각 edge는 실제 indexName, lockMode, lockData와 연결됩니다.
barrier.contention-captured
13 · COMMIT · A의 COMMIT 이후 대기 작업 재개

Session A가 COMMIT하면 보유 lock이 해제됩니다. 기다리던 UPDATE와 INSERT는 순서대로 완료되고 affected rows는 각각 1이며, deadlock은 발생하지 않습니다.
barrier.holder-commit-closed
14 · Session O · 새 transaction이 확인한 최종 3 rows

Session O의 새 read 결과는 job_id 102, 106, 103 순서입니다. INSERT된 priority 25 row가 사이에 들어오고 job_id 103은 revision 2, note updated-by-c로 보입니다.
barrier.final-observer-result

READ COMMITTED + SELECT ... FOR UPDATE

job_id 103 UPDATE는 기다리고 priority 25 INSERT는 바로 완료됩니다.

01 · Schema · Secondary index가 저장하는 정확한 tuple

idx_tenant_priority_job는 (tenant_id, priority, job_id) 순서로 정렬됩니다. job_id 101~105는 tenant_id 7의 seed row이고, job_id 201은 다른 tenant의 row입니다.
barrier.connections-ready
02 · Predicate · WHERE 절이 여는 [20, 40) 범위

tenant_id = 7, priority >= 20, priority < 40이 (7,20,102)와 (7,30,103)을 결과로 고릅니다. (7,40,104)는 반환되지 않는 upper range boundary입니다.
barrier.holder-read-complete
03 · EXPLAIN ANALYZE · range access와 실제 2 rows

MySQL 8.4.10은 idx_tenant_priority_job의 range access를 선택했습니다. native plan의 estimate는 rows=1, cost=0.71이고 EXPLAIN ANALYZE에서는 actual rows=2, loops=1입니다.
barrier.plans-captured
04 · Session A · Holder transaction 시작

Session A가 선택한 isolation level에서 transaction을 시작합니다. rr-plain은 일반 SELECT이고, 나머지 두 variant는 같은 SQL 끝에 FOR UPDATE를 붙여 locking read를 실행합니다.
barrier.connections-ready
05 · Session A · A가 읽은 row는 102와 103

Session A의 결과는 job_id 102(priority 20)와 103(priority 30)입니다. ORDER BY priority, job_id 순서와 secondary index 순서가 일치합니다.
barrier.holder-read-complete
06 · data_locks · Secondary RECORD와 PRIMARY row lock

rr-for-update에서 Session A는 secondary tuple (7,20,102), (7,30,103), 경계 (7,40,104)에 X lock을 보유하고 PRIMARY 102와 103에는 X,REC_NOT_GAP lock을 보유합니다.
barrier.contention-captured
07 · Session C · UPDATE는 PRIMARY 103에서 충돌

Session C가 WHERE job_id = 103인 UPDATE를 실행합니다. locking read가 있으면 PRIMARY 103의 X,REC_NOT_GAP 요청이 Session A의 granted row lock과 충돌해 COMMIT 전까지 기다립니다.
barrier.update-outcome-established
08 · Session B · INSERT는 (7,25,106) 위치를 요청

Session B의 INSERT는 secondary index에서 (7,20,102)와 (7,30,103) 사이에 (7,25,106)을 넣으려 합니다. rr-for-update에서 INSERT INTENTION은 다음 tuple (7,30,103)의 gap lock과 충돌합니다.
barrier.insert-outcome-established
09 · Wait evidence · 실제 data_lock_waits로 확인한 blocker

rr-for-update에는 C → A의 PRIMARY 103 wait와 B → A의 idx_tenant_priority_job (7,30,103) wait가 함께 나타납니다. rc-for-update에는 C → A row wait만 남습니다.
barrier.contention-captured
10 · B-tree interval · Next-key lock이 보호하는 index interval

Captured B wait의 LOCK_DATA는 (7,30,103)입니다. Next-key model에서 attempted (7,25,106)은 이 record 앞 gap에 놓이므로 Session A의 COMMIT을 기다립니다.
barrier.contention-captured
11 · Clustered index · Secondary tuple에서 PRIMARY row로 이동

secondary leaf의 carried primary key 102와 103을 따라 clustered PRIMARY row를 찾습니다. Session C의 UPDATE는 job_id 103 row를 바꾸므로 A가 보유한 PRIMARY 103 lock과 직접 충돌합니다.
barrier.contention-captured
12 · Wait graph · Session C와 B가 Session A의 어떤 lock을 기다리는지 확인하기

rr-plain은 wait edge가 없습니다. rr-for-update는 Session C와 B가 모두 A를 기다리고, rc-for-update는 Session C만 A를 기다립니다. 각 edge는 실제 indexName, lockMode, lockData와 연결됩니다.
barrier.contention-captured
13 · COMMIT · A의 COMMIT 이후 대기 작업 재개

Session A가 COMMIT하면 보유 lock이 해제됩니다. 기다리던 UPDATE와 INSERT는 순서대로 완료되고 affected rows는 각각 1이며, deadlock은 발생하지 않습니다.
barrier.holder-commit-closed
14 · Session O · 새 transaction이 확인한 최종 3 rows

Session O의 새 read 결과는 job_id 102, 106, 103 순서입니다. INSERT된 priority 25 row가 사이에 들어오고 job_id 103은 revision 2, note updated-by-c로 보입니다.
barrier.final-observer-result