最准方式是执行select @@transaction_isolation;返回repeatable-read（短横线、全大写），该值反映会话默认级别，但需在事务开始前设置且未被orm或连接池覆盖；若返回read-committed则说明未生效。
怎么确认当前会话确实是REPEATABLE READ？
别信文档或配置文件，直接查变量最准。很多人改了my.cnf却没重启 MySQL，或者只在会话里执行了SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ，但忘了验证是否生效。
执行这条语句：
SELECT @@transaction_isolation;
返回值要是REPEATABLE-READ（注意是短横线、全大写），不是repeatable read或REPEATABLE READ——MySQL 8.0+ 返回格式固定为带短横线的字符串。
- 如果返回
READ-COMMITTED，说明隔离级别根本没设对，不可重复读必然发生 -
@@tx_isolation在 8.0+ 已弃用，用它可能返回空或错误值 - 连接池场景下，即使应用代码里写了
SET SESSION，也要在实际执行 SQL 的连接上单独验证，因为连接可能被复用且残留旧状态
为什么BEGIN之后第一次SELECT才真正启动事务？
这是实操中最容易踩的坑：BEGIN只是标记事务起点，不生成ReadView；真正触发 MVCC 快照机制的是第一条快照读（即普通SELECT）。
典型误操作：
- 先
BEGIN，再UPDATE，再SELECT→SELECT才是事务第一次快照读，ReadView此时才生成，之前UPDATE看到的数据其实是当前读 - 只
BEGIN不执行任何 SQL 就去另一个终端改数据 → 原连接还没事务上下文，每次SELECT都是独立快照 - ORM 自动提交开启（如 Django 的
autocommit=True），BEGIN后没显式COMMIT或ROLLBACK，下一条语句就自动提交，事务已结束
验证方法：在事务内执行SELECT后，立刻在另一终端UPDATE ... COMMIT，再回原事务查——结果不变才算成功启动了可重复读。
混用当前读和快照读会导致“伪不可重复读”
看似两次SELECT结果不同，其实一次是快照读、一次是当前读。InnoDB 对SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE一律走当前读，绕过ReadView直接读最新已提交版本。
常见陷阱：
- 事务中先
SELECT id=1得到balance=100，中间别人改成200并COMMIT，再执行UPDATE SET balance = balance + 50 WHERE id = 1→ 这条UPDATE是当前读，读到200，最终写入250，业务逻辑错乱 - 用
SELECT ... FOR UPDATE锁行后，后续普通SELECT仍走快照读，但如果误以为“锁了就一直可见最新值”，就会困惑为什么读不到自己刚锁住的修改 - 非 InnoDB 表（如 MyISAM）完全不支持 MVCC，
REPEATABLE READ形同虚设
解决办法：需要强一致性的“读-改-写”逻辑，必须用SELECT ... FOR UPDATE发起当前读并加锁，或改用原子语句如UPDATE ... WHERE id = ? AND balance >= ?。
长事务导致ReadView膨胀影响判断
ReadView里维护着事务启动时所有活跃事务 ID 列表（m_ids）。如果事务长时间不执行任何查询（比如卡在应用层处理逻辑），m_ids会持续累积已提交但未清理的事务 ID，导致版本链遍历变慢，甚至出现误判。
这不是不可重复读，但会让排查变复杂：
- 执行
SHOW ENGINE INNODB STATUS查看TRANSACTIONS部分，留意Trx id counter和History list length是否异常高 - 长事务期间，其他事务的
DB_TRX_ID可能超过max_trx_id阈值，导致本该可见的版本被过滤 - undo log 被 purge 线程回收后，旧版本丢失，MVCC 失效 —— 此时即使隔离级别正确，也会报
Snapshot too old错误（尤其在 OLAP 场景）
真正难调试的点在于：现象像不可重复读，根源却是事务空转太久或 undo log 不足。缩短事务生命周期比调隔离级别更治本。
