MySQL生产环境必须弃用MyISAM，因其会导致8.0+启动失败、主从复制静默失效、崩溃后数据逻辑错乱且无法自恢复，ALTER转InnoDB也存在多重风险。
MySQL生产环境必须弃用MyISAM，不是“建议”，而是只要存在一个MyISAM表（尤其是系统表），就可能在重启、主从切换、升级或故障恢复时直接导致实例启动失败、复制中断或权限失效。
MyISAM表会导致MySQL 8.0+启动失败
MySQL 8.0.33+ 启动时会对mysql库所有系统表做引擎一致性校验。若其中任一表（如mysql.user、mysql.db）仍是MyISAM，服务会立即报错退出，典型错误是：ER_UNKNOWN_STORAGE_ENGINE: Unknown storage engine 'MyISAM' 或 MY-010929。这不是配置能绕过的——disabled_storage_engines=MyISAM只拦新建表，不修复已有表；skip-myisam在系统表加载阶段已无效。
常见误操作包括：
- 用旧版
mysqldump还原备份时未去掉ENGINE=MyISAM，导入后自动创建MyISAM表 - 执行
CREATE TABLE t AS SELECT * FROM myisam_table，新表沿用源表引擎，不触发白名单检查 - 误以为
mysql_upgrade能转换系统表——该工具自8.0.16起已被标记为deprecated，实际不再生效
ALTER TABLE ENGINE=InnoDB不是一键安全操作
线上业务表转InnoDB常被当作“简单命令”，但背后是全量拷贝+索引重建+聚簇重排，极易引发连锁问题：
- 操作期间表不可写，且大量刷脏页可能拖垮Buffer Pool，连带影响其他查询响应
- 临时磁盘空间需达原表1.5倍以上；空间不足时操作直接失败，且无法回退
- 含
FLOAT/DOUBLE字段且允许NULL的表，在部分8.0.x版本中会报错，必须先执行ALTER COLUMN ... SET DEFAULT 0 - 原有
FULLTEXT索引不会自动迁移，需手动DROP INDEX再ADD FULLTEXT
千万级表务必安排在低峰期，并提前验证磁盘空间与字段兼容性。
MyISAM在主从复制和高可用链路中静默失效
MySQL 8.0默认binlog_format=ROW，但MyISAM不支持行格式日志，复制链路会无声退化为STATEMENT模式。后果包括：
-
NOW()、UUID()、USER()等非确定性函数在主从产生不同值，审计/报表类业务逻辑错乱 - 从库执行
REPLACE INTO后看似成功，但金额或状态已错位，且无任何错误日志可查 - 主库执行
ALTER TABLE时，从库若仍为MyISAM，复制立刻中断，REPAIR TABLE无法恢复一致性 - 云厂商高可用方案（如InnoDB Cluster、MHA）依赖事务一致性与崩溃可恢复性，MyISAM表存在即意味着故障转移失败概率趋近100%
崩溃后MyISAM无法自检，数据错位却“看起来正常”
MyISAM没有UNDO LOG和REDO LOG，所有变更直接落盘到.MYD（数据）和.MYI（索引）文件。崩溃发生时：
- 索引与数据文件可能不同步，
SELECT COUNT(*)和SELECT * FROM t WHERE id > 1000返回矛盾结果 -
REPAIR TABLE只是暴力重建索引，不验证业务逻辑是否一致；SSD老化或I/O错误时，甚至可能越修越坏 -
read_only=ON对MyISAM无效：INSERT DELAYED和LOAD DATA INFILE仍可写入，彻底破坏只读语义 -
SELECT ... FOR UPDATE被静默忽略，应用层以为加了锁，实际并发写入仍在发生
真正危险的不是报错，而是表“能查、能连、能读”，但关键字段早已逻辑错乱——这种问题在线上压测或初期流量下几乎不会暴露，等订单、库存、账户类业务规模上来，修复成本远高于早期统一转换的成本。
