MyISAM在分布式事务中静默破坏原子性，因其不支持事务，START TRANSACTION被忽略，DML直接落盘，ROLLBACK无效，导致部分提交、脏状态和跨节点数据不一致。
因为分布式分库分表场景下，事务原子性、跨节点一致性、崩溃后可恢复这三件事，MyISAM 一个都做不到——它连 START TRANSACTION 都静默忽略，根本不是“性能差一点”的问题，而是直接让整个分布式事务链路失效。
为什么 MyISAM 在分布式事务中会静默破坏原子性
MySQL 分布式协调器（如 XA、Seata、ShardingSphere 的事务管理模块）依赖每个参与节点对 BEGIN/COMMIT/ROLLBACK 做精确响应。MyISAM 引擎不实现事务日志，也不维护 undo log，执行 START TRANSACTION 后所有 DML 操作仍直接落盘，ROLLBACK 无效，COMMIT 无意义。
- 现象：某分片写入成功但其他分片失败，MyISAM 节点无法回滚已写数据，留下脏状态
- 后果：下游查到“已支付但未生成订单”这类业务断层，人工对账成本陡增
- 验证方式：在 MyISAM 表上执行
BEGIN; INSERT INTO t VALUES (1); ROLLBACK;，再查表，数据仍在
分区表和分片路由共同要求行级锁与 MVCC
分库分表常配合 MySQL 原生分区（如按时间分 partition）或中间件路由（如 ShardingSphere 按 user_id 取模）。无论哪种，同一逻辑表的数据分散在多个物理节点，必须靠行级锁 + MVCC 提供并发安全视图。
- MyISAM 的表级锁会让一次
UPDATE阻塞整张表读写，哪怕只改一个分片里的某几行 - InnoDB 的行锁 +
read_view机制，使不同分片上的事务能各自看到一致快照，避免幻读、丢失更新 - 错误配置示例：在 ShardingSphere 中将 MyISAM 表设为分片表，单条 UPDATE 触发全表锁，导致下游服务批量超时
崩溃恢复必须依赖 WAL 和 doublewrite，而 MyISAM 没有
分布式系统节点宕机是常态。InnoDB 的崩溃恢复能力不是靠运气，而是靠 redo log（WAL）前滚 + undo log 回滚 + doublewrite buffer 防页损坏三者协同。MyISAM 仅靠 .MYD/.MYI 文件，崩溃后需人工运行 myisamchk，且无法保证修复结果与其他节点一致。
- 检查项：
SHOW VARIABLES LIKE 'innodb_log_file_size';、SHOW VARIABLES LIKE 'innodb_doublewrite'; - 云数据库陷阱：部分托管实例默认关闭
innodb_doublewrite，需手动开启 - 真实故障案例：MyISAM 分片节点断电重启后，
REPAIR TABLE修复了分区 A，但分区 B 仍损坏，同步中断且无法自动续传
MySQL 8.0+ 已移除 MyISAM 分区支持，强制锁定 InnoDB
从 MySQL 8.0 开始，CREATE TABLE ... PARTITION BY ... ENGINE=MyISAM 直接报错 ERROR 1031 (HY000)。5.7 是最后一个支持 MyISAM 分区的版本，但官方文档明确标注为 “deprecated”，且生产中极易触发元数据不一致。
- 迁移路径唯一：存量 MyISAM 分区表必须先
ALTER TABLE t ENGINE=InnoDB;，再重建分区 - 注意：该操作会锁全表并重写全部数据，必须在低峰期执行
- 别信“MyISAM 分区 COUNT(*) 更快”：分区后 MyISAM 也要逐个扫描每个
.MYD文件求和，实际比 InnoDB 的分区裁剪 + 索引遍历更慢
真正容易被忽略的是：InnoDB 的可靠性不来自“它支持事务”，而来自你是否让 innodb_flush_log_at_trx_commit=1、sync_binlog=1、innodb_doublewrite=ON 这些开关在真实负载下持续生效——它们才是分布式共识的底层锚点。
