MySQL InnoDB MVCC多版本并发控制原理与高性能实现

快照读为什么不用加锁？

简而言之，原因非常直接：InnoDB 从不直接获取最新行数据。每次 SELECT 操作，它都依据当前事务的 Read View，沿着版本链找到“该事务可见的最近版本”。整个过程中，行锁或表锁一概不碰。既然查询的是快照而非实时值，锁机制自然被绕开。

关键逻辑在于：一行被修改但未提交？其他事务完全不可见。若已提交但提交时间晚于当前事务启动，Read View 同样会将其排除。因此，读操作与写操作之间天然不存在冲突，实现了无锁并发。

• 在 RR（可重复读）隔离级别下，Read View 在事务第一次执行 SELECT 时生成，后续所有查询均复用该视图
• 在 RC（读已提交）隔离级别下，每次 SELECT 都会创建新的 Read View，因此能够看到其他事务最新提交的数据
• 若提升至串行化隔离级别，SELECT 操作退化为当前读，自动添加共享锁，此时 MVCC 机制直接失效

DB_TRX_ID和DB_ROLL_PTR怎么协同工作？

每一行数据背后，都隐藏着两个系统字段：DB_TRX_ID 记录最后一次修改该行的事务 ID，DB_ROLL_PTR 则指向 undo log 中该行的上一个版本。两者共同构成一条完整的版本链。

以事务 A 更新某行为例：InnoDB 首先将旧值拷贝到 undo log，然后设置新行数据的 DB_ROLL_PTR 指向该旧版本；同时将 DB_TRX_ID 更新为事务 A 的 ID。通过一系列指针串联，多个版本便形成了有序序列。

• 若 DB_TRX_ID = 0，表明该行已被标记为删除
• 若 DB_ROLL_PTR 为空，说明该版本是最早的，无法再向上追溯
• 版本链的头部是当前最新数据，尾部是最早的快照，通过 DB_ROLL_PTR 回溯即可遍历所有历史版本

Read View怎么判断一行是否可见？

Read View 并非存储在磁盘上的表，而是一组内存中的状态信息，包含：m_ids（创建时的活跃事务 ID 列表）、min_trx_id（其中最小活跃 ID）、max_trx_id（下一个待分配的事务 ID）以及 creator_trx_id（创建该视图的事务 ID）。

可见性判定逻辑非常清晰：将目标行的 DB_TRX_ID 与这组参数逐一比对。

• 如果 DB_TRX_ID 小于 min_trx_id，说明该行在 Read View 创建前已提交 → 可见
• 如果 DB_TRX_ID 大于等于 max_trx_id，说明该行由后续事务写入 → 不可见
• 如果 DB_TRX_ID 正好落在 m_ids 列表中，说明写入事务尚未提交 → 不可见
• 否则（既不在 m_ids 中，又满足 min_trx_id ≤ DB_TRX_ID），说明该行已提交且早于当前事务启动 → 可见

undo log空间爆满怎么办？

undo log 并非无限增长，它仅保留那些仍可能被访问的历史版本。一旦所有活跃事务不再需要某个版本——例如相关事务均已提交或回滚——Purge 线程便会清理对应的 undo log 段。

然而，长事务往往成为瓶颈。若一个事务长时间不提交，或者 innodb_max_purge_lag 设置过于保守，undo log 将不断累积。这不仅降低 DML 性能，甚至可能引发类似 ERROR 1205: Deadlock found when trying to get lock 的误报。

• 事务内避免长时间操作（如调用外部 HTTP 接口、循环处理大量数据）
• 通过 show engine innodb status 监控 Purge done for trx's n:n 的进度
• 必要时将 innodb_purge_threads 调整为 4（默认为 1，适用于高并发场景）
• MySQL 5.7 及以上版本，开启 innodb_undo_log_truncate = ON，配合 innodb_undo_tablespaces，支持自动截断

真正棘手的往往不是 undo 空间本身，而是那个迟迟不提交的事务——它像锚点般拖住整个版本链，导致所有依赖快照的查询都无法绕过它。