MyISAM放大单点故障风险，因其无事务、崩溃恢复弱、表级锁易阻塞，损坏后无法自动恢复，且STATEMENT复制模式下主从易不一致。
为什么MyISAM本身就会放大单点故障风险
MyISAM 引擎没有事务、崩溃恢复能力弱、表级锁在高并发下极易阻塞，这些不是“性能问题”，而是单点故障的温床。一旦某张 MyISAM 表因写入中断、索引损坏或磁盘满导致 Table 'xxx' is marked as crashed and should be repaired，整个查询或更新就会卡死——它不像 InnoDB 那样能靠 innodb_force_recovery 或 MVCC 回退，而是直接让连接 hang 住或报错退出，且无法自动恢复。
更关键的是：MyISAM 不支持 binlog_format=ROW 下的可靠复制，STATEMENT 模式在 NOW()、UUID()、触发器等场景下主从数据不一致，故障切换后可能读到错误余额或订单状态。
如何识别并清退存量 MyISAM 表
别依赖人工排查。用这条 SQL 扫全库：
SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE engine = 'MyISAM'
AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
重点检查业务库中以下高频风险表：
- 日志类表（如
user_login_log）——常被误设为 MyISAM 以图“快”，但实际写入并发一高就锁死 - 配置/字典表（如
sys_config）——虽读多写少，但若用 MyISAM，UPDATE会锁整表，拖慢所有依赖它的服务 - 临时汇总表（如
tmp_daily_report）——脚本未显式指定引擎时，默认可能继承旧模板的 MyISAM
转换命令必须带 ALGORITHM=INPLACE 和 LOCK=NONE（MySQL 5.6+）：
ALTER TABLE user_login_log ENGINE=InnoDB ALGORITHM=INPLACE LOCK=NONE;
注意：LOCK=NONE 不适用于含 FULLTEXT 索引的 MyISAM 表，需先 DROP INDEX 再转，否则会锁表数分钟。
应用层和部署层必须堵死 MyISAM 回流路径
即使当前没 MyISAM 表，只要建表语句没强制指定引擎，新表仍可能回退成 MyISAM——尤其当 default_storage_engine 被意外改回 MyISAM，或某些 ORM（如老版本 Django）生成 DDL 时不写 ENGINE=InnoDB。
必须做三件事：
- 在所有 MySQL 实例的
my.cnf中显式锁定默认引擎：default_storage_engine=InnoDB，且确认该配置加载顺序高于其他覆盖项（可用mysqld --verbose --help | grep "default-storage-engine"验证） - 在数据库初始化脚本或 CI/CD 的建表流程中，强制插入
ENGINE=InnoDB字符串，哪怕 ORM 生成的 SQL 缺失也补上 - 在备份恢复链路（如
mysqldump）中加--skip-create-options以外的防护：用sed或解析工具过滤掉输出中的ENGINE=MyISAM，防止 restore 时重建
漏掉任意一环，一次上线、一次灾备演练、一次手动 dump/restore，都可能把 MyISAM 带回来。
InnoDB 替换后仍要验证的两个隐性单点
把表引擎换成 InnoDB 只是起点。真正决定是否消除单点，看这两处：
-
innodb_flush_log_at_trx_commit=1必须开启——否则事务提交后日志只在内存，宕机即丢数据，等于用 InnoDB 做了 MyISAM 的事 - 所有涉及交易的关键表，主键必须是自增
BIGINT或业务无歧义的CHAR(32)，禁用UUID_SHORT()或时间戳前缀 ID，避免主从复制时因非确定性函数引发 GTID 跳过或执行失败
最易忽略的是：即使引擎全换成了 InnoDB，如果复制模式仍是 STATEMENT，且业务代码里写了 INSERT INTO log_table SELECT NOW(), ...，那主从延迟或切换后，时间字段就不可信——这不是引擎问题，而是复制语义漏洞，得靠 binlog_format=ROW + 全量校验兜底。
