MVCC仅在InnoDB中生效，因其依赖InnoDB特有的三个隐藏字段（db_trx_id、db_roll_ptr、db_row_id）、Undo Log日志系统及事务ID管理机制，而MyISAM等引擎既无这些字段，也不支持事务和Undo Log，无法构建版本链或生成ReadView。
为什么MVCC只在InnoDB中生效
MVCC不是MySQL服务器层的通用机制，而是InnoDB存储引擎独有的一套底层实现。它依赖InnoDB特有的数据结构和日志系统，其他引擎（如MyISAM、MEMORY）既没有对应字段，也没有配套日志，根本无法支撑MVCC运行。
缺少三个隐藏字段就等于没有MVCC基础
InnoDB每行数据自动维护db_trx_id、db_roll_ptr和可选的db_row_id——这三个字段是MVCC版本管理的物理载体。MyISAM表结构里完全不存在这些字段，插入/更新时不会记录事务ID，也不会保存回滚指针，自然没法构建版本链。
- 没有
db_trx_id，就无法标记“这行是谁改的” - 没有
db_roll_ptr，就找不到undo log里的历史版本 - 没有版本链，ReadView就无从判断某一行对当前事务是否可见
没有Undo Log，MVCC就是空中楼阁
MVCC的历史版本全部存在Undo Log里，而Undo Log是InnoDB事务四大日志之一。MyISAM不支持事务，压根没有Undo Log模块；崩溃恢复靠myisamchk人工修复，备份要全表加锁，更别说提供一致性快照了。
- 云数据库要求热备份、主从增量同步、崩溃自动恢复——这些能力都依赖Undo Log + Redo Log协同工作
- MyISAM一旦实例异常重启，表可能直接进
crashed状态，云平台会立刻告警并隔离 - 没有Undo Log，就无法生成ReadView，快照读（
SELECT）就退化成当前读，MVCC彻底失效
READ COMMITTED和REPEATABLE READ依赖InnoDB事务状态管理
MVCC在RC和RR级别下才起作用，而这两种隔离级别的行为差异，是由InnoDB在事务开启时生成的ReadView决定的。MyISAM连事务都不支持，BEGIN只是个空操作，COMMIT和ROLLBACK也无实际效果，更谈不上维护活跃事务列表或事务ID分配序列。
- RR级别下，同一个事务内多次
SELECT复用首次生成的ReadView；RC级别则每次查询都新建ReadView——这个逻辑只在InnoDB事务对象里实现 - 云数据库的读写分离代理（如ProxySQL）靠
TRX_STATE等InnoDB内部状态做路由决策，MyISAM查询一律被识别为“非事务型”，无法参与一致性读路由
真正关键的不是“为什么不用MyISAM做MVCC”，而是“InnoDB的这三个隐藏字段+Undo Log+事务ID管理是一整套耦合极深的基础设施，抽掉任何一块，MVCC就不可运行。这不是功能开关，是地基级依赖。”
