mysql默认在repeatable read下普通select为非阻塞快照读，不加锁；read committed每次生成新快照，read uncommitted和serializable不适用快照读，显式加锁或更新前定位等场景会退化为阻塞当前读。
MySQL的SELECT默认就是非阻塞快照读，但前提是你用对了隔离级别
MySQL InnoDB 默认在 REPEATABLE READ 隔离级别下，普通 SELECT（不带 FOR UPDATE 或 LOCK IN SHARE MODE）走的是 MVCC 快照读，不加锁、不阻塞其他事务的写操作。这不是“需要额外开启”的功能，而是引擎行为本身——但很多人误以为要手动配置或加 Hint 才能启用。
关键判断点：只要没显式加锁、没用 SELECT ... FOR UPDATE、且事务未开启 autocommit=0 后长期不提交（导致历史版本链膨胀），快照读就自然生效。
-
READ COMMITTED下每次SELECT生成新快照，REPEATABLE READ下事务内第一次SELECT建立一致性视图，后续复用 -
READ UNCOMMITTED不走 MVCC，直接读最新行版本，可能看到脏数据，也不算真正意义的“快照读” -
SERIALIZABLE下普通SELECT会隐式加上共享锁，退化为阻塞读
哪些SELECT语句会意外跳过MVCC，变成当前读？
一旦语句触发了“当前读”，就会加锁并读最新版本，丧失非阻塞特性。这不是 bug，而是语义所需，但容易被忽略。
-
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE：明确要求加锁，必然当前读 - 更新前的隐式定位：执行
UPDATE t SET x=1 WHERE id=100时，InnoDB 必须先读取id=100的最新行来加锁，这个“读”是当前读，会阻塞其他FOR UPDATE请求 - 唯一索引等值查询命中记录：在
REPEATABLE READ下，若WHERE条件命中唯一索引且记录存在，InnoDB 可能优化为当前读（尤其配合UPDATE或DELETE） - 主键或唯一索引范围查询（如
WHERE id > 100）也可能触发间隙锁+当前读，取决于执行计划
innodb_max_purge_lag和长事务会让快照读变慢甚至超时
MVCC 不是免费的。旧事务未提交，会阻止 purge 线程清理 undo 日志，导致历史版本链堆积。这时新事务构造一致性视图要遍历更长的版本链，SELECT 延迟上升，极端情况下触发 Lock wait timeout exceeded（即使你没加锁）。
- 监控
SHOW ENGINE INNODB STATUS中的HISTORY LIST长度，超过几万就要警惕 - 避免应用层开启事务后长时间空闲（比如交互式页面停留 5 分钟才提交）
-
innodb_max_purge_lag设得太低（如 10000）会让新 DML 主动 sleep，间接拖慢快照读响应，不推荐调优此参数来“保读性能” - 真正有效的做法是：业务侧控制事务粒度，用
SELECT ... INTO @var提前读取必要数据，再开小事务做写入
验证是否真正在用快照读：看INFORMATION_SCHEMA.INNODB_TRX和执行计划
别只信文档，现场查证最可靠。快照读不会出现在事务锁等待列表里，也不会在 INNODB_TRX 中显示锁信息。
- 执行一个长事务：
BEGIN; SELECT SLEEP(60);，再另起连接执行SELECT * FROM t WHERE id=1—— 如果立刻返回，说明是快照读；如果卡住，说明前一个事务持有了行锁且你触发了当前读 - 用
EXPLAIN FORMAT=JSON查看SELECT是否出现"access_type": "index"或"rows_examined_per_scan"异常高，可能是因 MVCC 版本过滤导致回表/遍历增多 -
SHOW ENGINE INNODB STATUS\G中关注TRANSACTIONS部分，快照读事务的lock_structs字段通常为 0
快照读的边界很细：它不解决写冲突，也不保证绝对实时，更依赖事务及时结束。最容易被忽视的，其实是开发习惯——比如 ORM 自动生成的 SELECT FOR UPDATE、或把整个 HTTP 请求生命周期包在一个事务里。
