MVCC是隔离机制副产品而非性能开关，仅在READ COMMITTED/REPEATABLE READ下的纯SELECT（无锁提示）触发快照读；加FOR UPDATE即退化为当前读；REPEATABLE READ通过快照“掩盖”幻读但更新仍作用于新行；长期事务、purge滞后、高频更新会导致undo膨胀与性能下降。

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 找出运行太久的事务。