快照读不加锁，是因为它不访问最新行版本而是通过undo log和readview读取事务可见的历史版本；在rr级别复用readview实现可重复读，rc级别每次新建readview，仅普通select为快照读，带锁提示或dml操作则触发加锁的当前读。
快照读不加锁，是因为它根本没碰当前行的最新版本
快照读（SnapShot Read）不加锁，不是“选择不加”，而是“加不上也无需加”——它压根不访问正在被修改的那行数据的最新物理记录，而是通过 undo log 回溯到事务可见的历史版本。InnoDB 在执行普通 SELECT 时，只查 ReadView 中判定为“对该事务可见”的那个版本，这个版本可能早已固化在 undo 页面里，和当前行锁无关。
常见错误现象：
– 你在事务 A 中执行 SELECT * FROM t WHERE id = 1，同时事务 B 正在对同一行做 UPDATE 并未提交；
– 事务 A 仍能立刻返回结果，且内容是事务开始前的值；
– 有人误以为这是“读到了脏数据”，其实是读到了自己事务视角下合法的快照版本。
-
READ COMMITTED隔离级别下，每次SELECT都生成新ReadView，快照粒度是语句级 -
REPEATABLE READ（InnoDB 默认）下，事务第一次SELECT时生成ReadView，后续所有快照读复用它，保证可重复读 - 只要没触发当前读（如
SELECT ... FOR UPDATE），就不会去竞争聚簇索引上的 record lock 或 gap lock
快照读依赖 undo log + ReadView 协同，不是“跳过锁”，而是“绕开锁”
所谓“无锁”，本质是读路径与写锁路径分离：写操作加锁、生成新版本、写入 undo log；读操作只根据 ReadView 中的 trx_ids 列表、min_trx_id、max_trx_id 和当前事务 ID 做可见性判断，然后从 undo log 链中捞出对应版本。整个过程不触碰聚簇索引记录头的 lock_bit 字段，自然不参与锁等待队列。
性能影响很直接：
– 大量并发 SELECT 不会阻塞 UPDATE，也不会被 UPDATE 阻塞；
– 但 undo log 空间持续增长（尤其长事务不提交），可能引发 Undo Log Full 或历史版本清理滞后。
- 如果事务长时间不提交，它的
ReadView会一直有效，导致大量旧版本无法 purge，占用空间 -
SELECT虽不加锁，但若底层需要遍历二级索引+回表，仍可能因consistent read需要构造多个版本而增加 CPU 开销 - 注意：快照读对
DELETE的处理是“逻辑删除”——被删行的版本仍保留在 undo 链中，直到事务提交且无活跃ReadView引用它
哪些操作看似是 SELECT，实际却是当前读？
不是所有 SELECT 都是快照读。只要语句带锁提示或涉及修改逻辑，InnoDB 就会强制走当前读路径，此时必然加锁，和 MVCC 无关。
-
SELECT ... FOR UPDATE→ 加X 锁，用于更新前占位 -
SELECT ... LOCK IN SHARE MODE→ 加S 锁，允许并发读但阻止写 -
UPDATE/DELETE/INSERT ... ON DUPLICATE KEY UPDATE内部第一步就是当前读，否则无法确定要改哪条记录 - 即使写的是
SELECT * FROM t WHERE id = 1，如果该语句出现在存储过程中被FOR UPDATE上下文包裹，也会变成当前读
最容易被忽略的一点：快照读的“一致性”只对本事务内有效，且仅限于已存在的行。它不防止幻读中的“新插入行”——REPEATABLE READ 下靠 Next-Key Lock 拦住间隙插入，但这属于当前读机制的延伸，和快照读本身无关。
