MySQL RR隔离级别下快照读看不到新插入行是MVCC+ReadView的正常设计：事务启动时生成ReadView，新行trx_id大于min_trx_id故不可见；当前读（如SELECT...FOR UPDATE）则绕过快照读取最新数据并加next-key lock。
MySQL可重复读（REPEATABLE READ）隔离级别下，数据“不可见”不是 bug，而是 MVCC + Read View 的确定性行为。关键不在于“修复不可见”，而在于明确你执行的是快照读还是当前读，以及是否误把“本不该看到的数据”当成了“应该看到却没看到”。
快照读为什么看不到新插入的行？
事务启动后第一次执行普通 SELECT 时，InnoDB 会生成一个 Read View，它固化了当时所有活跃事务 ID 的范围（m_ids 列表）、最小未分配事务 ID（min_trx_id）和创建视图的事务 ID（creator_trx_id）。后续所有快照读都基于这个视图判断数据版本可见性：
- 若某行的
trx_id小于min_trx_id，说明该行在视图创建前已提交 → 可见 - 若
trx_id在m_ids中，说明该行由其他未提交事务生成 → 不可见 - 若
trx_id大于min_trx_id且不在m_ids中，说明该行在视图创建后才提交 → 不可见
所以事务 A 启动后，事务 B 插入并提交的新行，其 trx_id 必然大于事务 A 的 min_trx_id，自然被过滤掉 —— 这是设计目标，不是问题。
当前读能绕过快照读限制吗？
能，但必须显式触发。快照读（SELECT）受 Read View 约束；当前读（SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE）会忽略 Read View，直接读取最新已提交版本，并加 next-key lock。
-
SELECT * FROM t WHERE id = 10 FOR UPDATE：读到事务 B 刚插入并提交的id = 10行（如果存在），同时锁住该记录及其间隙 - 但注意：
SELECT * FROM t WHERE id > 5 FOR UPDATE不会“自动补全”之前快照读漏掉的行 —— 它只对满足条件的**当前已存在行**加锁并读取最新值，不会让事务 A “回溯”看到自己快照里没有的行 - 真正影响并发行为的是锁，不是可见性：加锁后事务 B 的插入会被阻塞，从而从源头避免幻读现象发生
为什么有时候“快照读后写入”像幻读？
这是最易被误解的场景：事务 A 先 SELECT * FROM t WHERE c = 10（快照读，返回 0 行），再 INSERT INTO t (c) VALUES (10)。此时若事务 B 已插入并提交同值，A 的插入会报 Duplicate entry 或死锁 —— 表面像“读不到却写冲突”，本质是唯一索引约束在起作用，而非 MVCC 失效。
- 根本原因：唯一索引的等值查询不加间隙锁（
gap lock），只加记录锁（record lock），导致事务 B 能成功插入 - 解决方案不是改隔离级别，而是统一使用当前读：
SELECT * FROM t WHERE c = 10 FOR UPDATE，强制加next-key lock，堵住插入窗口 - 或在应用层加分布式锁 / 用
INSERT ... ON DUPLICATE KEY UPDATE消解冲突
哪些操作会意外破坏一致性预期？
真正引发“数据可见性困惑”的，往往是混合使用快照读与当前读，或依赖非主键/无索引字段查询：
- 在无索引字段上执行
SELECT ... FOR UPDATE：InnoDB 会升级为表级锁（table lock），极大降低并发，且可能锁住远超预期的行 - 使用
SELECT ... FOR UPDATE但 WHERE 条件未命中任何索引：同样触发全表扫描+全表加锁，性能雪崩 - 在 RR 级别下执行
UPDATE t SET x = 1 WHERE y = ?，而y无索引：不仅慢，还可能因锁范围过大导致事务 B 的插入被误阻塞 - 忘记
START TRANSACTION直接执行语句：每条语句自动成独立事务，Read View频繁重建，失去“可重复读”意义
复杂点从来不在 MVCC 本身，而在你是否清楚每一句 SQL 走的是快照路径还是加锁路径，以及索引是否存在、是否被命中。不看执行计划（EXPLAIN）就调优隔离级别，等于蒙眼修车。
