快照读不用加锁是因为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空间本身，而是那个迟迟不提交的事务——它像锚一样拽住整个版本链，让所有依赖快照的查询都绕不开它。
