快照读不会看到其他事务新插入的行，是因为它基于事务启动时生成的ReadView，通过MVCC和undo log回溯可见版本；在RR级别下ReadView固定，新插入行的TRX_ID大于up_limit_id，故不可见。
快照读为什么不会看到其他事务新插入的行
快照读的本质是读取事务启动时刻生成的一致性视图（ReadView），它不依赖当前数据页的最新状态，而是通过 undo log 链和 DB_TRX_ID、DB_ROLL_PTR 字段回溯可见版本。在 REPEATABLE READ 隔离级别下，这个 ReadView 在事务第一次执行快照读时就固定了，后续所有 SELECT（不带锁）都复用它。
所以即使另一个事务已 INSERT 并 COMMIT 了一行新记录，只要它的 TRX_ID 大于当前事务的 ReadView 中的 up_limit_id，这行就不会被看到——不是“没提交”，而是“不可见”。
- 快照读只对已存在且事务开启前就提交的行，或本事务自己改过的行可见
-
READ COMMITTED下每次快照读都会新建 ReadView，所以能看到其他事务刚提交的修改（但依然看不到未提交的插入） - 快照读不加锁，因此不会阻塞其他事务的
INSERT/UPDATE/DELETE
哪些 SQL 会触发当前读，以及它们加什么锁
当前读强制跳过 MVCC 快照机制，直接访问聚簇索引中最新版本的数据，并立即加锁。是否加锁、加什么锁（S 锁还是 X 锁），取决于语句类型和查询条件是否命中索引。
以下语句一律触发当前读：
-
SELECT ... FOR UPDATE→ 加X锁（行级或间隙锁，取决于执行计划） -
SELECT ... LOCK IN SHARE MODE→ 加S锁 -
UPDATE、DELETE→ 先当前读定位行，再加X锁 -
INSERT→ 对插入位置加INSERT_INTENTION锁（一种特殊的间隙锁）
注意：UPDATE t SET x=1 WHERE id = ? 和 UPDATE t SET x=1 WHERE name = ? 的锁范围可能完全不同——前者若 id 是主键，则只锁匹配行；后者若 name 无索引，则会升级为表级锁（或全聚簇索引扫描+每行加 X 锁）。
幻读只在当前读场景下暴露
很多人误以为“可重复读隔离级别能完全避免幻读”，其实只是快照读下幻读被 MVCC “掩盖”了。一旦你用 SELECT ... FOR UPDATE 去查一个范围，就立刻暴露问题：另一个事务在该范围内 INSERT 一行并提交后，你再次当前读，会看到新增行——这就是幻读。
InnoDB 的实际应对方式是：在当前读时，不仅对命中的记录加行锁，还会对查询范围加 **间隙锁（Gap Lock）** 或 **临键锁（Next-Key Lock）**，从而封锁“本不该存在新记录”的空隙。
- 例如
SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE，InnoDB 会锁住 (10, 20) 这个间隙，阻止其他事务插入 id=15 的新行 - 但如果查询条件用了函数（如
WHERE YEAR(create_time) = 2024）或非确定性表达式，间隙锁会失效，幻读风险回归 -
READ COMMITTED下默认禁用间隙锁，所以当前读也无法阻止幻读
autocommit=OFF 时，普通 SELECT 在 SERIALIZABLE 下会变成当前读
这是最容易被忽略的隐式行为。当 MySQL 的 autocommit 关闭，且事务隔离级别设为 SERIALIZABLE 时，所有不带锁的 SELECT 语句会被自动重写为 SELECT ... LOCK IN SHARE MODE。
也就是说，你以为在做快照读，实际上已经在加 S 锁了——这会显著降低并发度，还可能引发死锁，尤其在高频率只读场景下。
- 验证方式：开启事务后执行
SELECT，然后在另一连接尝试UPDATE同一行，会阻塞 - 如果真需要串行化但又不想锁表，应显式使用
SELECT ... FOR UPDATE控制锁粒度，而非依赖SERIALIZABLE的全局行为 - 生产环境极少使用
SERIALIZABLE，除非业务逻辑明确要求绝对顺序执行
关键点在于：快照读和当前读不是语法层面的区分，而是由语句是否加锁、隔离级别、甚至 autocommit 状态共同决定的运行时行为。同一个 SELECT，在不同上下文里可能是快照读，也可能是当前读——不能只看 SQL 字面。
