MySQL 8.0 中 MyISAM 已实质弃用：不支持原子 DDL、备份工具无法正确处理、主从复制易数据漂移、所谓“只读”场景实际风险极高，且 InnoDB 在读性能、功能覆盖上已全面超越，迁移成本远低于长期维护风险。
MySQL 8.0 中 MyISAM 已不是“可用但不推荐”，而是“名义存在、实际不可靠”——它既不能参与原子 DDL，也无法被备份工具正确识别，更关键的是：你看到的 ENGINE=MyISAM 很可能只是元数据残留，底层早已失效。
MyISAM 在 MySQL 8.0 中已失去系统级支持
MySQL 8.0 的数据字典完全基于 InnoDB 实现，所有系统表（mysql、performance_schema、information_schema）强制使用 InnoDB。这意味着：
- MyISAM 表无法参与原子 DDL 操作（如
ALTER TABLE ... RENAME或带外键变更的语句），失败时无法回滚，容易留下半截表 -
mysqldump --single-transaction会跳过 MyISAM 表，导致备份不一致；mysqlpump则直接报错Unknown storage engine 'MyISAM' - 复制环境中，MyISAM 表的 DML 不写入 binlog 的事务上下文，主从延迟或断连后极易出现数据漂移
“只读”假设在生产中极难成立
所谓“只读业务”，上线后往往很快出现意外写入路径：
- 运维手动
INSERT INTO log_table调试数据，触发全表锁，阻塞所有 SELECT - 应用日志轮转脚本执行
TRUNCATE TABLE，MyISAM 下该操作是隐式LOCK TABLES + DROP + CREATE，期间读请求全部超时 - 即使只用
SELECT COUNT(*)，高并发下也会争抢.MYI文件头元数据，形成文件系统级热点，QPS 上不去反掉得快
InnoDB 在纯读场景已无性能劣势
过去 MyISAM 的读优势（无事务开销、非聚簇索引回表快）在 MySQL 8.0 中基本消失：
- InnoDB 的
innodb_flush_log_at_trx_commit=2+innodb_doublewrite=OFF（仅限只读库）可大幅降低日志刷盘压力 - 8.0 的 InnoDB 支持快速索引构建（
ALGORITHM=INPLACE），且聚簇索引对主键等值查询的回表效率与 MyISAM 相当 - 全文索引、GIS 空间查询等曾是 MyISAM “刚需”的功能，InnoDB 自 5.6/5.7 起已完全覆盖，无需妥协
迁移成本远低于长期维护风险
把一张 MyISAM 表转成 InnoDB 并不复杂，但忽略它会埋下持续隐患：
-
ALTER TABLE t ENGINE=InnoDB在 8.0 中默认原子执行，不会中断服务（注意检查ROW_FORMAT和innodb_file_per_table配置） - 如果表有 FULLTEXT 索引，需先
DROP INDEX再重建——InnoDB 的全文索引结构不同，不能原地升级 - 迁移后务必验证
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE行为，避免旧应用依赖 MyISAM 的“无锁读”假定
真正棘手的从来不是“能不能转”，而是那些散落在 shell 脚本、ETL 任务、监控 SQL 里的 ENGINE=MyISAM 硬编码，以及开发人员脑中尚未刷新的“MyISAM 还能用”认知。这些地方一旦漏掉，升级后的某次 ANALYZE TABLE 或 OPTIMIZE TABLE 就可能让整个库卡住十几秒——而你根本想不到问题出在一张“只读”的字典表上。
