Engine Atlas

MySQL MVCC: REPEATABLE READ vs READ COMMITTED

secondary index · row versions · consistent read
MySQL 8.4.10captured evidence
한국어
Learning guide

Question for this Lab

After the writer commits, why do Session A under REPEATABLE READ and Session C under READ COMMITTED see different row versions for the same SELECT?

Execution engine: MySQL 8.4.10
Who runs it?

Sessions A and C run Q-01; Session B updates, deletes, and inserts, holds the transaction, then commits; and Session O observes a fresh result.

What stays controlled?

Q-01 fixes tenant_id = 7, state = 'READY', and FORCE INDEX (idx_tenant_state_order).

Executed SQL
SELECT order_id, amount_cents, revision, note
FROM mvcc_orders FORCE INDEX (idx_tenant_state_order)
WHERE tenant_id = 7
  AND state = 'READY'
ORDER BY order_id;
What changes?

The snapshot used by each statement and the visible row membership and payload change with the isolation level.

What stays fixed?

The SQL, fixture-backed version-chain explanation, index identifier, and committed writer changes stay fixed.

Predict before tracing

What appears in the second Q-01 after Session B commits?

What appears in the second Q-01 after Session B commits?

Evidence mission

Open the second-read step after Session B commits in the READ COMMITTED lane and check which row versions and membership become visible.

Where do you look?
Read the C2 result and result diff in the row-version lens for row 102's payload and the membership of rows 103 and 106.
Screen to open
READ COMMITTED · second-read membership
What should you see?
Expected observation

In its fresh statement snapshot C2 sees row 102 at amount_cents 2500, revision 2, includes row 106=6600, and row 103 is absent from the result. At the same point the REPEATABLE READ reader keeps 102=2400 and row 103 from its existing snapshot. That result membership is captured evidence, while the displayed delete mark and undo connection are Model content.

Evidence boundary
Captured
Q-01 second-read result rows and transaction order
Model
row-version chain and undo movement representation
Checkpoint · explain from evidenceDoes the displayed undo connection represent captured engine pointers and traversal?Reveal answer and basis

No. Q-01 results and transaction order are captured evidence, while the row-version chain and undo movement are fixture-backed Model content. No internal DB_TRX_ID or DB_ROLL_PTR value is invented.

Evidence boundary
Captured
Q-01 results and transaction order
Model
row-version chain and undo movement
Core takeaway

MVCC is not about one latest row; it is about which committed version each statement's read view is allowed to see.

Next connection

The next Lab adds FOR UPDATE and compares the resulting record, gap, next-key locks, and waits with a regular consistent read.

Review terms
consistent readIntroduced in Lab 07
An MVCC-based nonlocking SELECT that returns the row version visible to the transaction's read view.
REPEATABLE READIntroduced in Lab 07
An isolation level where consistent reads in one transaction reuse a snapshot to keep repeated query results stable.
READ COMMITTEDIntroduced in Lab 07
An isolation level where each consistent read uses a fresh snapshot as of the start of that statement.
undo recordIntroduced in Lab 07
An InnoDB record that retains pre-change row information for rollback and reconstruction of older snapshot-visible versions.

Current commandQ-01 definition
  1. A · RR readerRR reader · connection 12
    not-startedREPEATABLE READ
  2. B · RR writerWriter · connection 10
    not-startedREPEATABLE READ
  3. C · RC readerRC reader · connection 11
    not-startedREAD COMMITTED
  4. O · ObserverObserver · connection 13
    not-applicableREAD COMMITTED
01 · SOURCE

Q-01 reference

5 reference fragmentsMySQLQ-01 definition · secondary index · non-covering · ORDER BY
SELECT order_id, amount_cents, revision, note
FROM mvcc_orders FORCE INDEX (idx_tenant_state_order)
WHERE tenant_id = 7
  AND state = 'READY'
ORDER BY order_id;
02 · FLOW

Native plan and actual iterator

01 / 16
Plan metricsReference metrics

Reference values, not metrics for Q-01 definition

cost
0.35
estimated rows
1
actual time · first row ms
0.0348
actual time · last row ms
0.0362
actual rows
4
loops
1
repeatable-read EXPLAIN FORMAT=TREE-> Index lookup on mvcc_orders using idx_tenant_state_order (tenant_id=7, state='READY') (cost=0.35 rows=1)
DATA PATH

Secondary entries, row versions, and visible result

Model + Captured
Model
not-creatednone
INDEX

Secondary index entries

Derived · fixture
tenant_idstateorder_id · PKorigin
7READY101seed
7READY102seed
7READY103seed
7READY105seed
7READY106writer-insert
PRIMARY

Clustered row versions

Derived · fixture
order_idversionamount_centsrevisionnoteorigin
101101-seed12001seed-101seed
102102-before24001seed-102seed
102102-after25002updated-by-bwriter-update
103103-before-delete36001seed-103seed
105105-seed60001seed-105seed
106106-inserted66001inserted-by-bwriter-insert

Visible Q-01 result

Captured

Q-01 result has not run

Transaction isolation
1 / 16