MVCC是读写分离中从库快照读的底层支撑机制，依赖DB_TRX_ID、DB_ROLL_PTR和ReadView实现一致性非阻塞读，确保从库SELECT不被主库写锁阻塞，并在主从延迟时仍返回逻辑一致的历史版本。
因为读写分离依赖从库提供「一致性快照」，而这个快照能力完全由 InnoDB 的 MVCC 机制支撑；没有 MVCC，从库的普通 SELECT 就无法避开主库正在写的行锁，读请求会卡住或退化为加锁读。
从库的普通 SELECT 实际走的是快照读，不是实时拉最新数据
读写分离中，应用发往从库的 SELECT 默认不带 FOR UPDATE 或 LOCK IN SHARE MODE，属于「快照读」。InnoDB 必须靠 MVCC 构建事务开始时的数据视图（ReadView），才能让这条语句避开主库上未提交事务正在修改的行——否则就得等锁、阻塞、拖慢整个查询链路。
- 主库写入时只加行级 X 锁，但不会阻塞从库的快照读，前提是：从库事务能基于
DB_TRX_ID和DB_ROLL_PTR回溯到自己可见的历史版本 - 如果从库禁用 MVCC（比如误设隔离级别为
SERIALIZABLE），所有SELECT都变成当前读，必须加 S 锁，立刻和主库写冲突 - MySQL 8.0 默认隔离级别仍是
REPEATABLE READ，MVCC 自动启用；但若从库被显式设为READ COMMITTED，每次SELECT都生成新ReadView，仍依赖 MVCC 回滚链判断可见性
主从延迟下，MVCC 是唯一能保证「逻辑一致性」的机制
当主库已提交一条 UPDATE，但从库 relay log 还没重放完，此时从库的物理数据仍是旧值。MVCC 不是靠“等同步完成”来保证一致，而是靠 ReadView.m_ids 判断：该事务 ID 是否在从库当前活跃事务列表里。只要从库 SQL Thread 没执行完，那个写事务就仍在 m_ids 中，快照读就自动跳过它——用户看到的仍是事务开始前的状态，而不是半同步的脏中间态。
- 没 MVCC，只能靠锁或强制等待同步完成，吞吐量直接掉一半
-
DB_ROLL_PTR指向的 undo log 在从库也有效（重放时一并恢复），所以版本链可完整重建 - 注意：如果从库开启了
innodb_read_only=ON，undo log 仍可读，但不可写；MVCC 读路径不受影响
binlog 格式影响 MVCC 在从库的还原精度
从库回放 binlog 时，需重建行的隐藏字段（DB_TRX_ID、DB_ROLL_PTR）。这只有在 binlog_format=ROW 下才可靠；如果用 STATEMENT 格式，从库执行相同 SQL 时，DB_TRX_ID 会被设成本地事务 ID，导致版本链断裂、ReadView 判定失准，快照读可能看到不该见的版本。
- MySQL 8.0 默认
binlog_format=ROW，这是 MVCC 在从库正常工作的前提 - 混合模式（
MIXED）在某些函数（如NOW()）下会切回 statement，同样破坏隐藏字段一致性 - 验证方式：在从库执行
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX，观察事务 ID 是否与主库逻辑一致
MVCC 在读写分离中不是可选项，而是底层契约；一旦配置偏离（比如改隔离级别、换 binlog 格式、关 undo log purging），快照读就可能失效，而问题往往只在高并发或主从延迟时暴露——那时你看到的不是报错，而是随机不一致的查询结果。
