能，但有硬性限制：普通业务表可用MyISAM，系统表强制InnoDB；8.0默认禁用MyISAM，需显式配置启用；导出须避开--all-databases、替换ENGINE并清理ROW_FORMAT等残留参数。
MyISAM表在MySQL 8.0中是否还能用？
能，但有硬性限制：普通业务表可以继续用ENGINE=MyISAM，系统表（如mysql.user、mysql.db）强制要求InnoDB，否则启动失败或导入报错Storage engine 'MyISAM' does not support system tables。8.0默认禁用MyISAM引擎加载，若配置里没显式启用skip-innodb或default-storage-engine=myisam，连创建MyISAM表都会被拒绝。
导出时如何避免MyISAM引发的迁移失败？
关键不是“能不能导”，而是导出内容是否含8.0无法接受的MyISAM写法。必须做三件事：
- 绝对不用
--all-databases——它会把5.7的mysql库一起导出，而其中的MyISAM系统表在8.0里无法重建 - 导出命令显式指定业务库名，并加
--skip-extended-insert便于后续文本替换：mysqldump -u root -p --databases myapp_db --routines --triggers --default-character-set=utf8mb4 > myapp.sql - 导出后立刻执行
sed -i 's/ENGINE=MyISAM/ENGINE=InnoDB/g' myapp.sql，不要只替部分表——哪怕你确认某张表逻辑上适合MyISAM，8.0环境下统一用InnoDB更稳妥
导入前还要检查哪些MyISAM残留？
光改ENGINE不够，以下几类残留常被忽略，且会导致导入中断：
-
ROW_FORMAT=FIXED或ROW_FORMAT=COMPACT：8.0对MyISAM不支持这些参数，但即使已转InnoDB，旧dump里可能还带着；直接删掉整段ROW_FORMAT=xxx即可 -
KEY_BLOCK_SIZE：MyISAM特有，InnoDB不识别，删掉 -
DELAY_KEY_WRITE=1：MyISAM专用，InnoDB无对应行为，删掉 - 建表语句末尾的
COMMENT里若含MyISAM字样（比如历史备注），不会报错但易误导，建议一并清理
如果必须保留MyISAM表结构怎么办？
极少数场景（如只读归档表、全文索引旧实现）确实需要保留MyISAM，那必须满足三个前提：
- 目标8.0实例的
my.cnf里显式启用：default-storage-engine=myisam和skip-innodb（不推荐，破坏兼容性） - 确保该表**完全不参与任何系统权限、复制或触发器逻辑**——MyISAM表不支持事务、行锁、外键，一旦混入业务链路，主从延迟或数据不一致风险陡增
- 导入后立即执行
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'myapp_db' AND engine = 'MyISAM';验证，别依赖dump文件里的注释
真正麻烦的从来不是语法替换，而是那些没出现在CREATE TABLE语句里、却藏在应用逻辑深处的MyISAM假设——比如“这个表能承受高并发写”或“ALTER TABLE不会锁全表”。这些隐性依赖，比SQL本身更难排查。
