根本原因是myisam不支持事务，连start transaction都静默忽略，无法响应commit/rollback、无undo log回滚、无prepare状态持久化，导致分布式事务原子性、一致性与崩溃恢复全部失效。
分库分表方案中强制要求使用 InnoDB，根本原因不是“它更先进”，而是其他引擎在分布式数据切片场景下会直接破坏事务原子性、一致性或可用性——尤其是 MyISAM，连 START TRANSACTION 都静默忽略，根本没法参与分布式事务协调。
为什么XA或Seata等分布式事务协议必须依赖InnoDB
分布式事务协调器（如 MySQL 自带的 XA、ShardingSphere 的 Atomikos、或 Seata 的 AT 模式）需要底层引擎精确响应以下语义：
-
COMMIT和ROLLBACK必须真实生效，不能被忽略；MyISAM对COMMIT无反应，事务状态对协调器不可见 - 崩溃后必须能基于
undo log回滚未提交变更；MyISAM无 undo 机制，宕机后只能修复，且修复结果无法与其他节点对齐 - 两阶段提交（2PC）的 prepare 阶段需持久化中间状态；
InnoDB通过redo log+prepare标记保证，MyISAM完全不支持
一旦某个分片表用 MyISAM，整个分布式事务链路就退化为“尽力而为”，出现部分提交、下游查到脏数据、binlog 与实际数据不一致等问题。
分片路由后并发更新为何必须靠InnoDB行级锁+MVCC
分库分表后，同一逻辑表的数据分散在多个物理节点。若某节点用 MyISAM，会立刻暴露两个致命问题：
-
UPDATE或DELETE触发表级锁，导致该节点上所有对该表的读写全部阻塞——哪怕请求只改不同主键，QPS 也会断崖下跌 - 不同节点上的事务无法感知彼此的未提交变更：
MyISAM无read_view，无法提供快照读，同一查询在不同节点返回不一致结果，产生幻读或丢失更新 -
InnoDB的行锁绑定索引，只要分片键（如user_id）上有索引，跨节点更新不同用户就不会互相干扰
崩溃恢复不一致会直接击穿分布式共识
分库分表系统天然容忍单点故障，但前提是各节点崩溃后能恢复到**相同的一致状态**。这只有 InnoDB 能做到：
- 依赖
redo log前滚：只要日志落盘，重启就能重放至断电前最后已提交状态 -
MyISAM仅靠.MYD/.MYI文件，崩溃后需运行myisamchk，修复过程不可控、不可预测，且修复后的数据无法保证与其它节点 binlog 位点对齐 - 关键配置
innodb_flush_log_at_trx_commit=1和sync_binlog=1必须同时启用，否则即使用了InnoDB，仍可能丢事务
迁移MyISAM表时最容易踩的三个坑
线上存量 MyISAM 表迁移到 InnoDB 不是执行一条 ALTER TABLE t ENGINE=InnoDB 就完事：
- 该操作会锁表并重写全部数据，高峰期执行等于主动触发服务不可用；必须选低峰期，且提前评估磁盘空间（
InnoDB行格式更重，通常膨胀 20–50%） - 迁移后
SHOW TABLE STATUS中的Rows值可能严重不准——InnoDB是采样估算，MyISAM是精确计数；业务若依赖SELECT COUNT(*)结果做分页或限流，要改逻辑 - 原
MyISAM表若没主键，InnoDB会自建隐藏聚簇索引，后续ORDER BY或范围查询性能可能劣化；迁移前应显式添加主键
真正难的从来不是“怎么切”，而是切完之后，你的应用是否还假设“表锁不会发生”“COUNT 总是准的”“崩溃后数据自然一致”——这些隐含假设，在 MyISAM 上成立，在分库分表 + InnoDB 下必须逐一验证。
