MySQL可重复读通过MVCC和事务启动时生成的固定Read View确保同一行多次查询结果一致：快照读始终基于该视图从undo log版本链中查找事务开始时已提交的数据版本，屏蔽并发修改。
可重复读如何保证同一行数据多次查询结果一致
MySQL InnoDB 的 REPEATABLE READ 隔离级别能解决不可重复读，核心靠的是 MVCC（多版本并发控制） + 事务启动时固定 Read View。不是靠锁住整张表，也不是靠每次都查最新数据，而是让事务“活在自己的快照里”。
关键点在于：事务第一次执行普通 SELECT（即快照读）时，InnoDB 就会生成一个 Read View，它记录了当前活跃事务 ID 列表、最小未分配事务 ID（min_trx_id）、最大已提交事务 ID（max_trx_id）等信息。此后该事务内所有快照读都复用这个视图，只返回满足可见性规则的版本——也就是“对它可见的、且在它开始前已提交”的数据版本。
- 如果事务 B 在事务 A 启动后修改并提交了某行，B 的事务 ID 一定 > A 的
max_trx_id，所以 A 的Read View会忽略这个新版本 - 即使 B 的修改已落盘、binlog 已写入、从库已同步，A 仍看不到——这不是延迟，是设计上的“一致性快照”
- 这种机制天然屏蔽了其他事务对“已有行”的
UPDATE或DELETE，因此不可重复读（同一行两次查出不同值）被彻底避免
为什么不是靠行锁挡住更新
很多人误以为 REPEATABLE READ 是靠加锁防止别人改，其实不然。普通 SELECT 不加任何锁，是纯无锁读。真正加锁的是 SELECT ... FOR UPDATE、UPDATE、DELETE 这些当前读操作。
也就是说：SELECT * FROM user WHERE id = 1; 不会阻塞别人更新 id=1 的行；但如果你执行 SELECT * FROM user WHERE id = 1 FOR UPDATE;，那就会对这行加记录锁，别人就得等。
- 快照读不依赖锁，所以并发性能高，也不存在因锁等待导致的响应毛刺
- 但这也意味着：你读不到别人刚提交的更新，不是数据库“慢”，而是它故意不给你看
- 如果你需要看到最新值，就必须显式使用当前读，或接受
READ COMMITTED隔离级别
常见误解：UPDATE 后再 SELECT 看到新值，是不是破坏了可重复读
不会。比如事务 A 执行：
SELECT * FROM t WHERE id = 1; -- 返回 name='Alice' UPDATE t SET name='Bob' WHERE id = 1; SELECT * FROM t WHERE id = 1; -- 返回 name='Bob'
第二次 SELECT 看到新值，不是因为隔离级别失效，而是因为 UPDATE 是当前读，它会读最新版本并加锁；紧接着的 SELECT 很可能复用了这次更新后的最新行缓存（或触发隐式当前读），并不走原始 Read View。这不是违反可重复读，而是“写后读”场景下自然的行为。
- 可重复读约束的是“纯读事务”中多次快照读的一致性，不承诺写操作之后的读仍走旧快照
- 如果你在
UPDATE后还想验证旧快照，得显式用SELECT ... LOCK IN SHARE MODE或另起事务 - 实际业务中，这类混合读写逻辑必须明确区分快照读和当前读意图，否则容易出现预期外的数据可见性
唯一要注意的边界：快照读 vs 当前读混用时的“不一致感”
最易被忽略的点是：同一个事务内，快照读和当前读共存时，你会“同时生活在两个世界”。例如：
- 先
SELECT * FROM t WHERE id = 5;（没结果，快照读） - 别人插入
id=5并提交 - 你再
UPDATE t SET x=1 WHERE id = 5;（成功，当前读看到新行） - 再
SELECT * FROM t WHERE id = 5;（看到新行）
这看起来像“幻读”，但它本质是快照读和当前读语义切换导致的认知偏差。InnoDB 没有错，是你没意识到自己主动跳出了快照。
真正要警惕的，不是“能不能解决不可重复读”，而是“有没有混淆读类型”。一旦业务逻辑依赖“读到的数据一定能被后续更新影响”，就必须统一使用当前读，或提前加锁，不能默认靠快照读兜底。
