MyISAM 表无法实现主从复制的 crash-safe，因其不支持事务、无 redo/undo log，导致位点与数据错位；所有 crash-safe 配置（如 relay_log_info_repository=TABLE、sync_binlog=1）仅对 InnoDB 有效。
主从复制崩溃后，MyISAM 表的位点和数据必然错位
MySQL 主从复制要实现 crash-safe（崩溃安全），核心是让“SQL 线程执行到哪条 binlog”和“数据实际写入到什么状态”严格绑定。InnoDB 能做到这点，因为它的事务提交、binlog 写入、relay log 位点更新三者可通过 XID 关联，在一个原子事务中完成；MyISAM 完全没这个能力——它不参与事务，也没有 redo log 或 undo log。
常见错误现象：Slave_SQL_Running: No，Last_SQL_Error 显示 Table is marked as crashed 或 Got error 127 from storage engine，但 Seconds_Behind_Master 可能仍为 0，掩盖了逻辑不一致。
实操建议：
- 不要指望
myisam_recover_options能救场：MySQL 5.7+ 默认禁用自动修复，且REPAIR TABLE只重建索引，不校验数据行逻辑一致性 - 即使从库设为
read_only=ON，只要主库对 MyISAM 表执行了INSERT ... SELECT或含NOW()的语句，从库重放时就可能因函数值不同或锁冲突中断 SQL 线程 - STATEMENT 格式下 MyISAM 表看似能跑通，但这是假象：一旦主库宕机在 binlog 写完、表文件写入前，从库重放就会跳过该事件，造成数据丢失
crash-safe 配置只对 InnoDB 生效，MyISAM 会绕过所有保护机制
MySQL 提供的 crash-safe 参数（如 relay_log_info_repository = TABLE、relay_log_recovery = ON、sync_binlog = 1）底层都依赖 InnoDB 的事务能力。它们的作用是把 relay log 位点、gtid_executed 记录等元数据，和用户数据变更一起写进同一个 InnoDB 事务里。MyISAM 表的变更无法被纳入这个事务边界，等于在安全链条上硬生生断开一环。
实操建议：
-
relay_log_info_repository = TABLE必须配合 InnoDB 使用：它把位点存进mysql.slave_relay_log_info表，而该表必须是 InnoDB 引擎，否则位点更新和事务提交无法原子化 -
sync_binlog = 1和innodb_flush_log_at_trx_commit = 1（“双1”）只保障 InnoDB 数据与 binlog 同步；MyISAM 表的变更不受此约束，崩溃后可能 binlog 已落盘但 .MYD 文件损坏，或反之 - 启用了 MTS（多线程复制）还用 MyISAM？
sync_relay_log = 1也救不了——MyISAM 不支持基于行的并行回放，SQL 线程会退化为单线程甚至卡死
从库提升为主库时，MyISAM 直接成为单点故障源
高可用切换（MHA/Orchestrator/MGR）默认假设所有表具备崩溃可恢复能力。MyISAM 表在主库异常宕机后，从库拉起时大概率处于“索引与数据不同步”状态：查询 COUNT(*) 和 SELECT * 行数不一致、WHERE 条件返回空结果、甚至直接拒绝写入并报 Got error 1296。
这不是配置遗漏，而是 MyISAM 的设计决定它无法满足 Paxos 或多数派共识对状态一致性的基本要求。
实操建议：
- MGR 集群中，MyISAM 表会被硬拦截：
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin，连 DDL 都执行不了 - 即使不用 MGR，仅用传统主从做故障转移，也要检查
SHOW TABLE STATUS中所有表的Engine字段——只要有一个 MyISAM，整个切换流程就不可信 - 用
mysqldump --no-create-info --skip-triggers导出 MyISAM 表再导入新环境？风险极高：自增 ID、时间戳、全文索引行为全部可能错位，且 dump 过程中无法保证 binlog 位置连续
迁移 MyISAM 到 InnoDB 的真实卡点在哪
很多人知道“该换”，但一动手就踩坑：不是语法不会写，而是低估了引擎切换对复制链路、业务吞吐和系统元数据的影响。
实操建议：
-
ALTER TABLE t ENGINE=InnoDB在主库执行时，全程锁表（COPY 模式），期间该表所有 DML 阻塞，且 binlog 会记录完整建表 + 导入过程，从库需同步执行，延迟飙升 - 大表（>50GB）别直接在主库操作：先停从库 SQL 线程，在从库单独转换并验证
SELECT COUNT(*)与主库一致，再切主库 - 检查
FULLTEXT KEY：MySQL 8.0.16+ 已移除 MyISAM 全文索引支持，迁移到 InnoDB 后需重建为IN NATURAL LANGUAGE MODE或改用外部搜索引擎 - 别忽略
AUTO_INCREMENT行为差异：InnoDB 自增锁机制更严格，高并发插入可能出现间隙，若业务拿它当唯一标识，需重新评估
真正麻烦的从来不是“怎么转”，而是转完之后发现权限表、日志表、旧插件依赖的系统表还在用 MyISAM——这些表一旦残留，下次滚动重启或主从切换，就卡在 Waiting for table metadata lock 上动弹不得。
