InnoDB是主从复制唯一安全选择，因MyISAM不支持事务、无崩溃恢复、binlog与引擎状态无法对齐，易致数据错位、复制静默失败及一致性破坏；必须配innodb_flush_log_at_trx_commit=1、sync_binlog=1等参数保障强一致。
MySQL主从复制用InnoDB，不是“可以”，而是“必须”——除非你明确放弃数据一致性、崩溃恢复和主从同步可靠性。
为什么InnoDB是主从复制的唯一安全选择
MyISAM在主从场景下会直接破坏复制链路的底层契约：它不支持事务、无崩溃恢复能力、binlog与存储引擎状态无法对齐。一旦主库宕机或从库重启，SHOW SLAVE STATUS可能显示Seconds_Behind_Master: 0，但实际数据已错位。
- 主库写入时，InnoDB先写
redo log再更新缓冲池，崩溃后靠redo log重放恢复；MyISAM没有该机制，.MYD/.MYI文件可能处于中间态 - InnoDB的
binlog_format=ROW能精确记录每一行变更，从库回放时语义确定；MyISAM表遇到INSERT ... SELECT这类语句，在ROW模式下根本无法正确应用 - 从库执行
ALTER TABLE ENGINE=MyISAM后，复制线程会静默失败（错误日志只报ERROR 1594 (HY000): Relay log read failure），但SQL线程仍在运行，导致后续所有变更丢失
InnoDB主从复制中容易被忽略的配置依赖
光用InnoDB还不够，几个关键参数必须匹配，否则照样出问题：
-
innodb_flush_log_at_trx_commit=1+sync_binlog=1：保证每次事务提交都刷盘，这是强一致性的物理基础；设为0或2，主库崩溃就丢事务 -
transaction_isolation=REPEATABLE-READ：InnoDB默认隔离级别，配合MVCC和间隙锁，避免主从间幻读/不可重复读导致的校验不一致 -
innodb_support_xa=ON（MySQL 8.0.26前）：确保两阶段提交（2PC）正常工作，让binlog和redo log保持原子性 - 从库必须禁用
innodb_locks_unsafe_for_binlog（已废弃但旧配置可能残留）：否则间隙锁退化为表锁，阻塞并发查询
MyISAM在从库“加速查询”的陷阱
有人把大报表表转成MyISAM想省掉MVCC开销，结果反而更慢：
- MyISAM的
key_buffer_size只缓存索引，字段数据全靠随机IO读.MYD文件；而InnoDB的innodb_buffer_pool_size同时缓存数据页和索引页，QPS通常更高 - MyISAM的
SELECT COUNT(*)虽快，但前提是表真的一次没写过；只要凌晨跑过聚合脚本，.MYI里的行数就失效，CHECK TABLE常报error: 134，必须REPAIR TABLE锁表 - ProxySQL等中间件检测到MyISAM表无事务上下文，会误判为“需强一致性”，把本该路由到从库的查询打到主库，加重主库压力
真正需要MyISAM的极少数场景
当前（2026年）只剩一个勉强成立的用例：离线备份恢复后的临时校验表——整库mysqldump导出+mysql导入后，用MyISAM建一张只读校验表跑MATCH AGAINST做文本比对。但这张表必须满足三个硬条件：完全不写入、不参与复制、运行环境可控（如单机离线环境）。任何一条不满足，就立刻退回InnoDB。
