MySQL InnoDB如何借助多版本并发控制MVCC实现高性能

快照读不用加锁是因为InnoDB通过Read View在版本链中查找事务可见的最近版本，而非直接读取最新行；DB_TRX_ID标识修改事务，DB_ROLL_PTR链接旧版本构成版本链，Read View依m_ids、min_trx_id、max_trx_id和creator_trx_id判断可见性。

快照读为什么不用加锁？

因为InnoDB不直接读最新行，而是根据事务的Read View去版本链里找“该事务可见的最近版本”。这个过程完全不涉及行锁或表锁——SELECT查的是快照，不是当前值。

关键点在于：只要事务没提交，它的修改对其他事务不可见；而已提交但晚于当前事务启动时间的修改，也被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）。

判断某行是否可见时，InnoDB拿该行的DB_TRX_ID和Read View比对：

• 如果DB_TRX_ID ，说明这行在<code>Read View生成前就已提交 → 可见
• 如果DB_TRX_ID >= max_trx_id，说明这行由未来事务写入 → 不可见
• 如果DB_TRX_ID在m_ids里，说明写它的事务还没提交 → 不可见
• 否则（DB_TRX_ID不在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（默认1，高并发可设为4）
• innodb_undo_log_truncate = ON（MySQL 5.7+）配合innodb_undo_tablespaces支持自动截断

真正难处理的不是undo空间本身，而是那个迟迟不提交的事务——它像锚一样拽住整个版本链，让所有依赖快照的查询都绕不开它。