MySQL 的 MVCC 不是性能优化开关，而是隔离机制的副产品
MVCC 本身不直接“提升查询性能”，它解决的是并发读写冲突问题；但正因为读操作（
SELECT）通常不加锁、可访问快照，才间接让高并发读场景更流畅。如果你在
READ COMMITTED或
REPEATABLE READ隔离级别下观察到查询变快，大概率是因为避免了锁等待，而不是 MVCC 自身做了加速。
哪些查询能真正受益于 MVCC 的快照读
只有满足「一致性非锁定读」条件的
SELECT才走 MVCC 快照路径。这要求： 事务隔离级别为
READ COMMITTED或
REPEATABLE READ（
READ UNCOMMITTED和
SERIALIZABLE不适用） 语句是纯
SELECT，不含
FOR UPDATE、
LOCK IN SHARE MODE等显式锁提示 没有被其他事务的写操作阻塞（比如正在执行的
UPDATE持有行锁） 查询字段全部来自当前版本可见的 undo log 记录（即未被后续事务覆盖或删除）
一旦加上
SELECT ... FOR UPDATE，哪怕只查一行，也会退化为当前读，触发行锁和 gap lock，MVCC 快照机制就失效了。
REPEATABLE READ
下的幻读与快照边界
很多人误以为
REPEATABLE READ能完全避免幻读——其实只是靠 MVCC 快照“掩盖”了新插入的行。同一事务中多次执行相同
SELECT，看到的数据集一致，但这不等于底层没变化。
START TRANSACTION; SELECT * FROM orders WHERE status = 'pending'; -- 返回 5 行 -- 此时另一个事务 INSERT 了一条新 pending 订单并 COMMIT SELECT * FROM orders WHERE status = 'pending'; -- 仍返回 5 行（快照可见性决定）
这种“一致性”代价是：如果后续执行
UPDATE ... WHERE status = 'pending'，会更新所有符合条件的行（包括刚才那个新插入的），导致业务逻辑与快照视图不一致。这是 MVCC 带来的典型认知陷阱。
容易被忽略的性能损耗点：undo log 膨胀与 purge 压力
MVCC 依赖 undo log 存储历史版本，但这些日志不会自动消失。以下情况会让 undo 空间持续增长，拖慢查询：
存在长期未提交的事务（哪怕只是空闲连接），会阻止 purge 线程清理旧版本innodb_max_purge_lag设置过低，导致 purge 跟不上写入速度，进而使新查询被迫等待 purge 大事务批量更新后立刻查询，可能触发大量版本链遍历，CPU 开销上升 频繁更新同一行（如计数器字段），产生长版本链，
SELECT需要逐个检查可见性
用
SHOW ENGINE INNODB STATUS查看
HISTORY LIST长度，超过几万就要警惕；配合
information_schema.INNODB_TRX找出运行太久的事务。
