REPEATABLE READ 的快照读在事务第一次普通 SELECT 时生成 Read View，后续快照读均基于此视图；BEGIN 不触发快照创建，非 InnoDB 引擎不支持 MVCC，混用快照读与当前读或修改事务隔离级别会破坏一致性。
REPEATABLE READ 的快照读机制到底怎么工作
MySQL 的 REPEATABLE READ 能防不可重复读，前提是用对了读法：它靠 MVCC 在事务**第一次普通 SELECT 执行时**生成一个一致性视图（Read View），后续所有不带锁的 SELECT 都基于这个快照——哪怕其他事务已提交修改，你也看不到。
关键不是“设了隔离级别就万事大吉”，而是事务是否真正启动、是否触发了快照创建。常见误区是只执行 BEGIN 就以为事务已活，其实没发任何 SELECT，Read View 就没生成，第二次查自然可能看到新数据。
- 事务启动时机 = 第一条普通
SELECT执行时刻，不是BEGIN时刻 -
SELECT * FROM t WHERE id = 1是快照读；SELECT * FROM t WHERE id = 1 FOR UPDATE是当前读，绕过快照，直接读最新已提交版本 - 使用非 InnoDB 引擎（如 MyISAM）时，
REPEATABLE READ完全无效，MVCC 不存在
为什么你设了 REPEATABLE READ 还看到不一致结果
现象：同一事务内两次 SELECT 返回不同值。这不是 MySQL 实现有 bug，而是环境或操作踩了坑。
最常被忽略的三个点：
- 客户端连接未重连：Navicat/DBeaver 修改会话级隔离级别后，旧连接仍沿用原设置，必须断开重连才生效
- 混用快照读和当前读：先
SELECT（快照），再SELECT ... FOR UPDATE（当前读），之后又SELECT——中间若其他事务提交了修改，你可能误以为“快照失效”，其实是当前读污染了判断逻辑 - 事务内执行了写操作：比如先
UPDATE某行，再SELECT同一行，InnoDB 允许读到本事务刚写的值（“本事务可见性”），这不属于不可重复读，但容易被当成异常
哪些操作会悄悄破坏可重复读语义
不是所有 SQL 都走快照。以下情况会让事务“突然看到新数据”，看似违反隔离，实则是设计如此：
-
SELECT ... LOCK IN SHARE MODE和SELECT ... FOR UPDATE：强制当前读，跳过 MVCC 快照，读最新已提交版并加锁 - 涉及
information_schema或系统表的查询：这些表不走 MVCC，始终返回物理最新状态 -
JOIN查询中，若被 JOIN 的表被其他事务修改并提交，且该表无合适索引，优化器可能退化为块嵌套循环，导致部分行读新、部分读旧 - 显式降级隔离级别：在事务中执行
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，后续读立即切换为每查新建快照
真要强一致性，别只靠隔离级别
如果业务要求“判断 + 修改”必须原子，比如“只有 status = 'pending' 才能 update 成 'shipped'”，靠两次独立 SELECT + UPDATE 一定有窗口期——哪怕在 REPEATABLE READ 下，中间也可能被并发改掉。
更可靠的做法是合并为单条语句：
UPDATE orders SET status = 'shipped' WHERE order_id = 123 AND status = 'pending';
它天然具备“读-判-改”原子性，且只影响匹配行，无需额外锁等待。而依赖 SELECT ... FOR UPDATE 虽能加锁，但会阻塞其他事务，且容易引发死锁——尤其当多个事务按不同顺序访问行时。
真正难处理的，从来不是隔离级别本身，而是应用层把“读一致性”和“写安全性”混在一起想，又没做原子化约束。
