MySQL 事务与隔离级别深度解析：ACID、MVCC 与间隙锁实战

注：标准 SQL 定义中 RR 不保证幻读，但 InnoDB 通过间隙锁在特定条件下解决了此问题。

三、MVCC：为什么 REPEATABLE READ 能避免不可重复读？

如果 MVCC 没理解透彻，很容易混淆快照读和当前读的区别。

1. 什么是不可重复读？

同一个事务内，多次读取同一行数据，结果不一致。通常是因为中间有其他事务提交了修改。

-- 事务 A
START TRANSACTION;
SELECT balance FROM accounts WHERE user_id = 100; -- 返回 1000
-- 此时事务 B 执行 UPDATE... COMMIT;
SELECT balance FROM accounts WHERE user_id = 100; -- 仍返回 1000 (RR 级别)
COMMIT;

在 READ COMMITTED 级别，第二次查询会看到 1500；而在 REPEATABLE READ 级别，只要 Read View 不变，就始终看到旧版本。

2. InnoDB 的 MVCC 核心机制

每行数据都有两个隐藏字段：

• DB_TRX_ID：最后修改该记录的事务 ID
• DB_ROLL_PTR：指向 undo 日志的指针，用于回溯历史版本

当数据被修改时，InnoDB 不会直接覆盖，而是将原数据备份到 undo 日志，并更新指针。这就形成了版本链。

3. Read View：事务的'时间窗口'

Read View 定义了事务能看到哪些数据版本。它包含活跃事务 ID 列表（m_ids）、最小/最大事务 ID 等。

关键区别：

• READ COMMITTED：每次 SELECT 都创建新的 Read View，能看到其他事务最新已提交的数据。
• REPEATABLE READ：仅在事务首次普通 SELECT 时创建 Read View，整个事务期间复用该视图。

4. 可见性判断规则

当事务读取一行时，InnoDB 沿版本链查找：

1. 若记录 DB_TRX_ID = creator_trx_id，可见（当前事务自己改的）。
2. 若 DB_TRX_ID < min_trx_id，可见（修改发生在 Read View 创建前且已提交）。
3. 若 DB_TRX_ID ≥ max_trx_id，不可见（修改发生在未来）。
4. 若在 m_ids 中，不可见（事务还在运行）；否则可见。

5. 例外：当前读打破一致性视图

REPEATABLE READ 只保证普通 SELECT（快照读）的一致性。以下操作会读取最新已提交数据并加锁：

• SELECT ... FOR UPDATE
• SELECT ... LOCK IN SHARE MODE
• UPDATE, DELETE, INSERT

-- 事务 A (REPEATABLE READ)
START TRANSACTION;
SELECT balance FROM accounts WHERE user_id = 100; -- 返回 1000.00
-- 事务 B 修改并提交
SELECT balance FROM accounts WHERE user_id = 100 FOR UPDATE; -- 返回 1500.00!
COMMIT;

当前读会获取最新版本，突破 MVCC 的限制。

四、幻读真相：为什么需要间隙锁？

1. 幻读 vs 不可重复读

• 不可重复读：同一行数据被修改（值变了）。
• 幻读：新行插入导致结果集行数变化（多了几条）。

2. 幻读发生场景

-- 事务 A
SELECT * FROM orders WHERE user_id = 1001; -- 返回 0 条
-- 事务 B
INSERT INTO orders (user_id) VALUES (1001); -- 提交
-- 事务 A
SELECT * FROM orders WHERE user_id = 1001; -- 返回 1 条（幻读！）

MVCC 只能解决'数据修改'的问题，无法阻止'新行插入'。要解决这个问题，必须靠间隙锁（Gap Lock）。

3. 间隙锁工作流程

间隙锁锁住索引之间的间隙，阻止其他事务在该范围内插入新记录。

-- 事务 A
SELECT * FROM orders WHERE user_id = 1001 FOR UPDATE; -- 加间隙锁
-- 事务 B
INSERT INTO orders (user_id) VALUES (1001); -- 阻塞！
-- 事务 A
COMMIT; -- 释放锁
-- 事务 B
INSERT ... -- 现在可以执行

生效条件：

1. 必须使用 SELECT ... FOR UPDATE 或类似锁定查询。
2. 查询条件必须是索引列。

InnoDB 在 REPEATABLE READ 级别下，对于范围查询会自动启用间隙锁（Next-Key Lock），从而在大多数情况下避免幻读。

五、实战避坑指南

1. 没索引 ≈ 锁整张表

SELECT * FROM log WHERE create_time < '2025-06-01' FOR UPDATE;

如果 create_time 没有索引，InnoDB 只能全表加间隙锁，瞬间导致线程飙升。

建议：

• 先用 EXPLAIN 查看执行计划，确认 rows 列。
• 范围列 + 业务主键建立联合索引，让锁落在必要间隙。

2. 常见误区

• 误区 1：认为 REPEATABLE READ 保证全局一致。
  • 真相：只保证事务内一致，其他事务已提交的数据对后续事务可见。
• 误区 2：认为 SELECT ... FOR UPDATE 锁住所有行。
  • 真相：只锁住匹配的行及间隙。
• 误区 3：盲目使用 SERIALIZABLE。
  • 真相：会导致全表锁，高并发下性能急剧下降。

六、事务实战：安全转账代码级解析

-- 事务 A（转账）
START TRANSACTION;
-- 1. 读取余额（加锁）
SELECT balance FROM accounts WHERE user_id = 1001 FOR UPDATE;
-- 锁定 user_id=1001
-- 2. 扣减余额
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1001;
-- 3. 增加余额
UPDATE accounts SET balance = balance + 100 WHERE user_id = 1002;
COMMIT;

安全性分析：

• FOR UPDATE 加行锁 + 间隙锁，阻止其他事务插入新订单或修改余额。
• MVCC 保证事务内余额查询一致（避免不可重复读）。
• 事务提交后，数据状态满足原子性。

七、总结

事务的本质是平衡一致性与并发性能。

1. ACID 实现核心：

   • 原子性：redo log 保障崩溃恢复
   • 一致性：应用层逻辑兜底
   • 隔离性：MVCC + 间隙锁（REPEATABLE READ）
   • 持久性：redo log + binlog 落盘

2. 隔离级别真相：

   • 不要迷信 SERIALIZABLE，性能代价太大。
   • 默认 REPEATABLE READ 在 InnoDB 中表现优异，但需注意当前读行为。

3. 幻读解决关键：

   • 标准 SQL 中 RR 不保证幻读，但 InnoDB 通过间隙锁实现了事实上的保护。
   • 务必确保查询条件走索引，否则间隙锁退化为全表锁。

掌握这些机制，才能在生产环境中写出既安全又高效的 SQL。