分布式事务必须使用innodb引擎，因其支持acid、行级锁、mvcc、wal崩溃恢复及外键约束；myisam不支持事务与原子性，会导致部分提交、脏状态、表锁阻塞、数据不一致及备份中断。
分布式事务要求所有节点支持完整ACID语义
MySQL分布式架构（如MGR、ShardingSphere分片集群、或跨实例XA事务）中，事务协调器必须依赖底层引擎对BEGIN、COMMIT、ROLLBACK和崩溃后undo log回滚的精确实现。MyISAM不支持事务，连START TRANSACTION都只是静默忽略——一旦某个节点用MyISAM表参与分布式写入，整个事务链路就失去原子性保障，出现“部分提交、无法回滚”的脏状态。
实操建议：
- 检查所有参与分布式事务的表：执行
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';，确认无MyISAM或MEMORY引擎 - 建表时显式指定：
CREATE TABLE t (...) ENGINE=InnoDB;，避免依赖默认值（某些旧部署可能改过default_storage_engine） - 迁移存量MyISAM表必须用
ALTER TABLE t ENGINE=InnoDB;，且需在低峰期执行——该操作会锁表并重写全部数据
跨节点并发更新依赖行级锁与MVCC一致性视图
分布式场景下，同一逻辑表的数据常分散在多个物理节点。若某节点用MyISAM，其表级锁会在UPDATE或DELETE时阻塞全表读写；而InnoDB的行级锁+MVCC机制允许不同节点上的事务并发修改不同主键范围的行，且各节点能基于read_view提供隔离级别一致的快照读。
常见错误现象：
- 分片路由到MyISAM节点后，单条
UPDATE导致整张表不可读，引发下游服务超时雪崩 - 同一业务请求在两个节点上开启事务后，MyISAM节点无法感知其他节点的未提交变更，产生幻读或丢失更新
性能影响：MyISAM表在高并发写入时，表锁争用会使QPS骤降50%以上；InnoDB虽有redo log刷盘开销，但通过组提交（innodb_log_group_commit）可大幅缓解。
故障恢复必须依赖WAL日志与崩溃一致性
分布式系统节点宕机是常态。InnoDB的WAL（Write-Ahead Logging）机制确保：只要redo log落盘，即使实例崩溃，重启后也能前滚恢复到断电前最后一致状态。而MyISAM仅靠.MYD/.MYI文件，崩溃后需运行myisamchk修复，且无法保证修复后数据与其它节点一致——这直接破坏分布式共识。
关键配置差异：
-
innodb_flush_log_at_trx_commit=1（默认）：每次事务都刷redo log，牺牲少量性能换强持久性，分布式环境必须启用 -
sync_binlog=1：配合binlog保证主从/分片间日志顺序一致，MyISAM无法提供事务级binlog事件边界 - 禁用
innodb_doublewrite=OFF：虽提升写入速度，但磁盘部分写失败会导致页损坏，分布式中难以定位和修复
外键与约束在分片逻辑中虽不跨节点，但单节点内仍需完整性兜底
虽然分布式架构通常禁止跨分片外键（因无法高效校验），但在单个MySQL实例内，业务表之间仍有强关联（如order→order_item）。若这些表混用MyISAM，插入order_item时无法触发父表order的外键检查，导致孤立记录；而InnoDB能在本地强制约束，避免数据模型腐化。
容易被忽略的点：
- 即使不用外键，InnoDB的聚簇索引结构让主键查询比MyISAM的非聚簇索引快20%~30%，这对分布式查询路由后的单节点热点访问很关键
- MyISAM的
AUTO_INCREMENT是表级缓存，主从切换时易重复；InnoDB的auto_inc_lock_mode=2（默认）支持并发安全分配，适配分布式写入 - 备份工具如
mysqldump --single-transaction只对InnoDB生效，MyISAM必须加全局读锁，破坏分布式服务SLA
