Understanding MVCC (Multi-Version Concurrency Control) in MySQL InnoDB

Hello everyone, I’m Chen, and today we’ll dive deep into MVCC, a long‑standing topic in MySQL that many developers only vaguely recall.

What is MVCC?

MVCC (Multi-Version Concurrency Control) is an optimistic‑lock based method used to achieve the READ COMMITTED and REPEATABLE READ isolation levels. In MySQL, MVCC is implemented by the InnoDB storage engine, not by MySQL itself, and different storage engines have their own implementations.

InnoDB solves concurrency by storing multiple versions of a row; each transaction works with its own snapshot, allowing SELECT operations to run concurrently.

Undo Log

The Undo Log is one of MySQL’s three main logs. When a row is modified, an undo record is created to allow rollback to a previous version. Each clustered index record contains two hidden fields: trx_id (the ID of the transaction that last modified the row) and roll_pointer (a pointer to the previous version stored in the Undo Log).

Example: a row with id=1 is inserted by transaction A (trx_id=10). When transaction B (trx_id=20) updates the row, the trx_id becomes 20 and roll_pointer points to the undo record created by transaction A.

Read View

A Read View holds a list of active (uncommitted) transactions. It contains four important fields: creator_trx_id , m_ids (IDs of active transactions), min_trx_id , and max_trx_id . These fields are used to decide whether a row version is visible to the current transaction.

How MVCC Implements Repeatable Read

When two transactions (A with ID 20 and B with ID 30) operate on the same row, each creates its own Read View. Transaction A reads the row, compares the row’s trx_id with its own creator_trx_id, and determines visibility based on the interval rules. If the row’s trx_id is less than A’s creator_trx_id and not in the active list, A reads the committed version; otherwise it follows the Undo Log chain to find a visible version.

How MVCC Implements Read Committed

Read Committed prevents dirty reads. If a row has been modified by an uncommitted transaction (its trx_id appears in the current transaction’s m_ids list), the reading transaction will skip that version and use the Undo Log to locate the latest committed version.

Summary

In InnoDB, MVCC works through Undo Log + Read View . The Undo Log stores historical snapshots, while the Read View rules determine the visibility of a version. This combination enables both read‑committed and repeatable‑read isolation without locking, and together with Next‑Key Locks it also prevents phantom reads.

Final Note (Support the Author)

The author has compiled three series of articles into PDFs (Spring Cloud, Spring Boot, MyBatis). Readers can obtain them by following the public account “码猿技术专栏” and replying with the corresponding keywords.