不可重复读指同一事务内多次SELECT返回不同结果，仅在READ COMMITTED隔离级别下稳定发生；REPEATABLE READ通过MVCC快照读和一致性视图避免该问题，SELECT不加锁但基于事务启动时的已提交版本快照。
什么是不可重复读，它在什么隔离级别下真实发生
不可重复读是指同一个事务中，多次执行相同的 SELECT 语句，返回了不同结果（比如某行数据被其他事务更新并提交）。它**只会在 READ COMMITTED 隔离级别下稳定复现**，而不会在 REPEATABLE READ 下出现——这不是靠锁，而是靠 MVCC 的快照读机制。
关键点在于：MySQL 默认的 REPEATABLE READ 并非标准 SQL 定义的“可重复读”，它通过一致性视图（consistent read view）把事务启动时刻的已提交版本“冻结”为快照，后续所有普通 SELECT 都基于这个快照，自然读不到其他事务后来的修改。
为什么 SELECT 不加锁却能避免不可重复读
因为 SELECT 在 REPEATABLE READ 下默认是**快照读（snapshot read）**，不访问最新版本，也不加行锁；它从 undo log 中按事务 ID 判断可见性，回溯到本事务可见的最近已提交版本。
这背后依赖三个核心结构：
-
DB_TRX_ID：每行记录隐式保存最后修改它的事务 ID -
DB_ROLL_PTR：指向该行旧版本在 undo log 中的位置 - 事务启动时生成的
read view：包含m_ids（活跃事务 ID 列表）、min_trx_id、max_trx_id和creator_trx_id
判断某版本是否可见的逻辑是：trx_id → 已提交，可见；<code>trx_id ∈ m_ids → 正在运行，不可见；trx_id ≥ max_trx_id → 启动后才开始，不可见。
哪些操作会破坏快照读，导致不可重复读重现
不是所有读都走快照。以下情况会退化为**当前读（current read）**，直接访问最新版本，并加锁，从而可能看到新数据：
- 显式加锁读：
SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE - 写操作：
UPDATE、DELETE、INSERT（含唯一键冲突检测） - 任何对同一行先
SELECT（快照读）再UPDATE的组合，在UPDATE时都会触发当前读，查最新版+加锁
典型陷阱：在一个长事务里，前半段用普通 SELECT 查到 A=1，中间别的事务把 A 改成 2 并提交，后半段执行 UPDATE t SET A = A + 1 WHERE id = 1 —— 这条 UPDATE 是当前读，读到的是 A=2，最终写入 A=3，造成逻辑错乱。这不是 MVCC 失效，而是混用了快照读和当前读。
如何验证当前事务的 read view 是否生效
MySQL 不提供直接查看 read view 的接口，但可通过 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS（8.0+ 已移除，改用 performance_schema.data_locks）间接观察行为。更实用的方式是构造可验证场景：
-- 会话 A（REPEATABLE READ） START TRANSACTION; SELECT * FROM t WHERE id = 1; -- 返回 A=1 <p>-- 会话 B START TRANSACTION; UPDATE t SET A = 2 WHERE id = 1; COMMIT;</p><p>-- 会话 A 再执行 SELECT <em> FROM t WHERE id = 1; -- 仍返回 A=1（快照读生效） SELECT </em> FROM t WHERE id = 1 LOCK IN SHARE MODE; -- 返回 A=2（当前读，绕过快照）</p>
真正容易被忽略的是：快照读的“起点”是 第一个普通 SELECT 执行时刻，不是 START TRANSACTION 时刻（除非启用了 innodb_locks_unsafe_for_binlog 或使用了 BEGIN 而非 START TRANSACTION）。如果事务开头先执行了 SELECT ... FOR UPDATE，那整个事务就从当前读开始了，后续普通 SELECT 也受其影响——这点连很多 DBA 都会误判。
