MySQL 8.0 生产环境必须弃用 MyISAM，因其会导致启动失败、主从复制错乱、只读失效及高危转换风险，系统表残留即引发 ER_UNKNOWN_STORAGE_ENGINE 错误，业务表须手动转为 InnoDB。
MySQL 8.0 生产环境必须弃用 MyISAM——这不是“建议”，而是确定性风险规避。只要系统表或业务表中残留一个 MyISAM，下次主从切换、滚动重启或 mysql_upgrade 就可能卡死在 Waiting for table metadata lock，且无法安全修复。
MySQL 8.0 启动时直接拒绝加载 MyISAM 系统表
MySQL 8.0+ 启动流程中，mysql 库（含 mysql.user、mysql.db 等）是最早加载、最后释放的元数据核心。一旦发现其中任一表仍为 MyISAM，部分版本（如 8.0.33+）会直接报错退出：
ER_UNKNOWN_STORAGE_ENGINE: Unknown storage engine 'MyISAM'
这不是配置能绕过的校验，而是元数据层引擎一致性强制检查。你无法靠 skip-myisam 或 disabled_storage_engines=MyISAM 让它“假装看不见”——因为系统表本身已不被允许用该引擎。
-
mysqld --upgrade=FORCE是唯一能触发自动转换的路径，但仅对系统表有效，业务表仍需手动处理 - 若误留
MyISAM表，在集群扩缩容或 MHA 切换时，新主库启动失败概率接近 100% -
REPAIR TABLE在 8.0+ 中已被弱化，对崩溃后的MyISAM表成功率极低，甚至可能破坏权限状态
主从复制下 MyISAM 表必然导致数据静默错乱
MySQL 8.0 默认 binlog_format=ROW，而 MyISAM 不支持行格式日志，复制链路会无声退化为 STATEMENT 模式，引发两类硬伤：
-
NOW()、UUID()、USER()等非确定性函数在主从产生不同值，报表/审计类业务直接失效 - 常见报错：
ERROR 1032 (HY000): Can't find record in 'xxx'或ERROR 1594 (HY000): Relay log read failure - 即使从库手动转成
MyISAM，只要主库执行ALTER TABLE，复制立刻中断，且REPAIR TABLE无法恢复一致性 -
read_only=ON对MyISAM无效：INSERT DELAYED和LOAD DATA INFILE仍可写入，彻底破坏只读语义
ALTER TABLE ENGINE=InnoDB 不是简单命令，而是高危操作
ALTER TABLE t ENGINE=InnoDB 表面一行，背后是全量拷贝、索引重建、聚簇重排。线上千万级表执行时，极易踩坑：
- 操作期间表不可写，且 Buffer Pool 被大量刷脏页，可能拖慢其他查询
- 临时磁盘空间需达原表 1.5 倍以上，空间不足直接失败
- 若表含
FLOAT/DOUBLE字段且允许NULL，某些 8.0.x 版本会报错，需先ALTER COLUMN ... SET DEFAULT 0 - 原有
FULLTEXT索引不会自动迁移，必须手动DROP INDEX再ADD FULLTEXT - 切完后务必确认
disabled_storage_engines=MyISAM已启用，防止应用层误建新MyISAM表
所谓“只读场景用 MyISAM 更快”是过时认知
MyISAM 的 COUNT(*) 优势仅存在于空缓存、单线程、无 WHERE 条件的玩具测试中。真实报表负载下，InnoDB 综合表现更稳更快：
-
innodb_stats_method=sampled可让带WHERE的COUNT(*)避免全表扫描，比 MyISAM 元数据计数更准 - 热数据常驻
innodb_buffer_pool_size，IO 效率远高于 MyISAM 的.MYD/.MYI分离文件随机访问 - 从库设
innodb_flush_log_at_trx_commit=2+sync_binlog=0后，纯读 QPS 反超 MyISAM 20%~40% - 真正该调的是 InnoDB 只读适配项，不是倒退回一个已被官方放弃维护的引擎
最危险的不是知道要换，而是没意识到自己还在用——很多老系统建表没显式指定 ENGINE，升级后默认已是 InnoDB，但遗留的 MyISAM 表长期无人检查，直到某次滚动重启才暴露。这种隐患不会预警，只会突然阻断整个数据库可用性。
