MVCC详解

sequenceDiagram
    participant TxA as 事务A
    participant TxB as 事务B
    participant DB as 数据库

    Note over DB: 初始状态: balance = 500

    TxA->>DB: BEGIN
    TxB->>DB: BEGIN

    TxA->>DB: UPDATE user SET balance = 1000 WHERE id = 1
    Note right of DB: 数据被修改但未提交<br/>balance = 1000 (未提交)

    TxB->>DB: SELECT balance FROM user WHERE id = 1
    DB-->>TxB: 返回 1000 ❌ (脏读!)
    Note right of TxB: 读到了未提交的数据

    TxA->>DB: ROLLBACK
    Note right of DB: 事务A回滚<br/>balance = 500 (恢复原值)

    Note over TxB: 事务B基于错误的1000进行后续操作
    TxB->>DB: UPDATE other_table SET total = total + 1000
    TxB->>DB: COMMIT

    Note over DB: 数据不一致!<br/>实际balance=500，但other_table基于1000计算

sequenceDiagram
    participant TxA as 事务A
    participant TxB as 事务B
    participant DB as 数据库

    Note over DB: 初始状态: 表中有3条age>18的记录

    TxA->>DB: BEGIN
    TxB->>DB: BEGIN

    TxA->>DB: SELECT COUNT(*) FROM user WHERE age > 18
    DB-->>TxA: 返回 3 ✅
    Note right of TxA: 第一次查询: 3条记录

    TxB->>DB: INSERT INTO user (name, age) VALUES ('张三', 20)
    TxB->>DB: COMMIT
    Note right of DB: 事务B插入新记录<br/>现在有4条age>18的记录

    TxA->>DB: SELECT COUNT(*) FROM user WHERE age > 18
    DB-->>TxA: 返回 4 ❌ (幻读!)
    Note right of TxA: 第二次查询: 4条记录<br/>出现了"幻影"记录

    TxA->>DB: COMMIT

    Note over TxA,DB: 问题: 同一事务内相同查询条件<br/>返回的记录数量不同

🎯 MVCC核心思想

• 读不阻塞写：读操作不会阻塞写操作
• 写不阻塞读：写操作不会阻塞读操作
• 版本管理：为每个数据行维护多个版本
• 时间戳机制：通过事务ID确定数据可见性

graph TD
    subgraph "时刻T1: 初始插入"
        A1[id=1, name='Alice', balance=1000<br/>trx_id: 100<br/>DB_ROLL_PTR: NULL]
        style A1 fill:#e8f5e8
    end

    subgraph "时刻T2: 事务101修改"
        B1[id=1, name='Alice', balance=800<br/>trx_id: 101<br/>roll_pointer: ptr1]
        B2[undo log<br/>id=1, name='Alice', balance=1000<br/>trx_id: 100<br/>roll_pointer: NULL]
        B1 --> B2
        style B1 fill:#fff3cd
        style B2 fill:#f8f9fa
    end

    subgraph "时刻T3: 事务102修改"
        C1[id=1, name='Alice', balance=600<br/>trx_id: 102<br/>roll_pointer: ptr2]
        C2[undo log<br/>id=1, name='Alice', balance=800<br/>trx_id: 101<br/>roll_pointer: ptr1]
        C3[undo log<br/>id=1, name='Alice', balance=1000<br/>trx_id: 100<br/>roll_pointer: NULL]
        C1 --> C2 --> C3
        style C1 fill:#ffe6e6
        style C2 fill:#f8f9fa
        style C3 fill:#f8f9fa
    end

    A1 -.-> B1
    B1 -.-> C1

6.23 快照读和当前读

快照读： 读取的是记录数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读,如：

select * from core_user where id > 2;

当前读：读取的是记录数据的最新版本，显式加锁的都是当前读

select * from core_user where id > 2 for update;
select * from account where id>2 lock in share mode;

6.3 ReadView机制

ReadView是MVCC的核心组件，实际上在innodb中，每个SQL语句执行前都会得到一个Read View。它决定了当前事务能看到哪些版本的数据。

6.3.1 ReadView的组成

Read View是如何保证可见性判断的呢？我们先看看Read view 的几个重要属性

6.3.2 ReadView生成时机

不同隔离级别下，ReadView的生成时机不同：

6.4 可见性判断算法

当事务要读取某行数据时，需要通过可见性判断算法确定应该读取哪个版本。

6.4.1 判断流程

对于版本链中的每个版本，按以下顺序判断：

1. 如果 trx_id == creator_trx_id
   → ✅ 可见（自己修改的数据）

2. 如果 trx_id < min_trx_id
   → ✅ 可见（ReadView生成前已提交的事务）

3. 如果 trx_id >= max_trx_id
   → ❌ 不可见（ReadView生成后开始的事务）

4. 如果 min_trx_id <= trx_id < max_trx_id
   → 检查trx_id是否在m_ids中
     - 在m_ids中：❌ 不可见（未提交的活跃事务）
     - 不在m_ids中：✅ 可见（已提交的事务）

5. 如果当前版本不可见，沿着roll_pointer查找上一个版本
   → 🔄 重复以上判断过程
   

7. MVCC在不同隔离级别下的表现

为了具体理解MVCC的作用，我们通过一个场景来分析不同隔离级别下的行为。

场景设定：

1. 事务A (Trx ID: 201): 启动事务，准备读取数据。
2. 事务B (Trx ID: 202): 启动事务，将user表中id=1的balance从1000修改为800，然后提交。
3. 事务C (Trx ID: 203): 启动事务，将user表中id=1的balance从800修改为600，然后提交。

7.1 READ COMMITTED (读已提交)

在此隔离级别下，每次SELECT都会生成一个新的ReadView。

sequenceDiagram
    participant TxA as 事务A (ID 201)
    participant TxB as 事务B (ID 202)
    participant TxC as 事务C (ID 203)
    participant DB as 数据库

    TxA->>DB: BEGIN
    TxB->>DB: UPDATE and COMMIT
    Note right of DB: 版本链: 800(trx_id=202) ->> 1000(...)

    TxA->>DB: SELECT (第一次)
    Note right of DB: 生成 ReadView_1
    DB-->>TxA: 返回 800

    TxC->>DB: UPDATE and COMMIT
    Note right of DB: 版本链: 600(trx_id=203) ->> 800(...)

    TxA->>DB: SELECT (第二次)
    Note right of DB: 重新生成 ReadView_2
    DB-->>TxA: 返回 600 (不可重复读)

7.2 REPEATABLE READ (可重复读)

在此隔离级别下，只有在事务第一次SELECT时才生成ReadView，后续查询将复用此ReadView。

sequenceDiagram
    participant TxA as 事务A (ID 201)
    participant TxB as 事务B (ID 202)
    participant TxC as 事务C (ID 203)
    participant DB as 数据库

    TxA->>DB: BEGIN
    TxB->>DB: UPDATE and COMMIT
    Note right of DB: 版本链: 800(trx_id=202) ->> 1000(...)

    TxA->>DB: SELECT (第一次)
    Note right of DB: 生成 ReadView_1
    DB-->>TxA: 返回 800

    TxC->>DB: UPDATE and COMMIT
    Note right of DB: 版本链: 600(trx_id=203) ->> 800(...)

    TxA->>DB: SELECT (第二次)
    Note right of DB: ❗️复用 ReadView_1
    DB-->>TxA: 返回 800 (保证可重复读)

sequenceDiagram
    participant TxA as 事务A (READ COMMITTED)
    participant TxB as 事务B (REPEATABLE READ)
    participant TxC as 事务C (修改数据)
    participant DB as 数据库

    Note over TxA,DB: READ COMMITTED 隔离级别
    TxA->>DB: BEGIN
    TxB->>DB: BEGIN

    TxA->>DB: SELECT * FROM user WHERE id=1
    Note right of DB: 生成ReadView_1
    DB-->>TxA: balance = 1000

    TxC->>DB: UPDATE user SET balance=800 WHERE id=1
    TxC->>DB: COMMIT

    TxA->>DB: SELECT * FROM user WHERE id=1
    Note right of DB: 重新生成ReadView_2
    DB-->>TxA: balance = 800 (读到最新数据)

    Note over TxB,DB: REPEATABLE READ 隔离级别
    TxB->>DB: SELECT * FROM user WHERE id=1
    Note right of DB: 生成ReadView_3 (首次)
    DB-->>TxB: balance = 800

    TxC->>DB: UPDATE user SET balance=600 WHERE id=1
    TxC->>DB: COMMIT

    TxB->>DB: SELECT * FROM user WHERE id=1
    Note right of DB: 复用ReadView_3
    DB-->>TxB: balance = 800 (保持一致)

    TxA->>DB: COMMIT
    TxB->>DB: COMMIT

8. MVCC的局限性与优化

虽然MVCC带来了显著的性能提升，但也存在一些局限性和需要优化的地方。

8.1 主要局限性

8.2 优化策略

8.2.1 Purge机制

MySQL InnoDB通过Purge线程定期清理不再需要的undo log版本：

8.2.2 长事务监控

-- 查找长时间运行的事务
SELECT
  trx_id,
  trx_started,
  trx_query,
  TIMESTAMPDIFF(SECOND, trx_started, NOW()) as duration_seconds
FROM information_schema.INNODB_TRX
WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 300
ORDER BY duration_seconds DESC;

8.2.3 配置优化

-- 相关配置参数
SET GLOBAL innodb_max_purge_lag = 1000000;        -- 控制purge延迟
SET GLOBAL innodb_purge_threads = 4;              -- purge线程数
SET GLOBAL innodb_undo_tablespaces = 2;           -- undo表空间数量

9. MySQL如何解决幻读问题

在上面我们提到，mysql默认使用RR隔离级别，也就是可重复读。但仅靠MVCC只能解决快照读可能发生的幻读问题，但并没有解决当前读场景下的幻读问题。于是mysql又引入了Next-Key-Locking来配合MVCC解决幻读问题。

MySQL在默认的REPEATABLE READ隔离级别下，通过结合使用 MVCC (多版本并发控制) 和 Next-Key Locking (临键锁) 这两种技术来解决幻读问题。

这两种技术分别应对不同的场景：

1. MVCC：解决“快照读”（普通SELECT）场景下的幻读。
2. Next-Key Locking：解决“当前读”（SELECT...FOR UPDATE, UPDATE, DELETE）场景下的幻读。

9.1 MVCC：解决“快照读”的幻读

对于普通的SELECT查询，InnoDB使用的是快照读。

• 工作原理：在REPEATABLE READ级别下，当事务第一次执行SELECT时，会创建一个ReadView（读视图）。这个ReadView记录了当前所有活跃（未提交）的事务ID。在整个事务的生命周期内，所有的SELECT查询都会复用这个初始的ReadView。
• 如何防幻读：
• 当事务A进行范围查询时，它只能看到那些“在ReadView创建之前就已经提交的”数据行。
• 如果此时事务B插入了一行新数据并提交，这行新数据的事务ID必然晚于事务A的ReadView。
• 根据MVCC的可见性判断算法，这行新数据对事务A是不可见的。
• 因此，无论事务A执行多少次相同的SELECT查询，结果集都不会改变，也就避免了幻读。

简单来说，MVCC通过“在事务开始时拍下一张快照”，让这个事务在后续的读取中永远只认这张“照片”里的数据，从而实现了“读”的隔离。

9.2 Next-Key Locking：解决“当前读”的幻读

当你的操作不是简单的SELECT，而是需要读取并可能修改数据的当前读操作时（例如UPDATE、DELETE或SELECT ... FOR UPDATE），单靠MVCC就不够了。这时，InnoDB会使用锁机制来防止幻读，这个锁就是Next-Key Lock。

什么是Next-Key Lock？

Next-Key Lock是两种锁的结合体：

1. Record Lock (记录锁)：锁定单条索引记录。
2. Gap Lock (间隙锁)：锁定索引记录之间的“间隙”，防止其他事务在这个间隙中插入新数据。

Next-Key Lock = Record Lock + Gap Lock

工作原理

• 当一个事务执行一个范围查询的UPDATE或DELETE操作时，InnoDB不仅会给匹配到的已有记录上Record Lock，还会给这些记录之间的所有间隙上Gap Lock。
• 它甚至会给最后一个记录之后到无穷大的这个“超级”间隙也上一个Gap Lock。

场景示例

假设有一个products表，其中有price为80, 100, 120的记录。

1. 事务A执行：

   BEGIN;
   UPDATE products SET status = 'on_sale' WHERE price > 100;
   

2. InnoDB加锁：

• 它会给price = 120的记录加上Next-Key Lock。
• 它会给(100, 120)这个间隙加上Gap Lock。
• 它还会给(120, +∞)这个间隙也加上Gap Lock。

3. 事务B尝试插入：

   BEGIN;
   INSERT INTO products (price) VALUES (110);
   

4. 结果：

• 事务B的INSERT操作试图在(100, 120)这个间隙中插入新数据。
• 但这个间隙已经被事务A的Gap Lock锁住了。
• 因此，事务B的INSERT操作会被阻塞，直到事务A提交或回滚释放锁为止。

通过这种方式，Next-Key Lock阻止了任何可能导致幻读的INSERT操作，从而完美地解决了在“当前读”场景下的幻读问题。

9.3 总结

正是这种MVCC + 锁的混合模式，使得MySQL的InnoDB引擎在REPEATABLE READ级别下就能达到几乎和SERIALIZABLE级别一样的隔离效果，同时又提供了远超后者的并发性能。

至此本文详细探讨了Mysql是如何利用MVCC来解决并发环境下可能出现的事务并发问题。如有错误，可以在评论区指出，一起商讨。