mysql 8.0强制要求系统表必须使用innodb引擎，myisam被彻底移除而非仅不支持；若启动时报er_unknown_storage_engine或my-010929错误，说明mysql库中存在myisam表，须通过mysqld --upgrade=force触发内核级转换，并排查权限、残留.frm文件及磁盘空间问题。
MyISAM 在 MySQL 8.0 中不是“不再支持”，而是被强制移除——系统表（如 mysql.user、mysql.db）必须是 InnoDB，否则实例根本无法启动或持续运行。这不是可选项，是硬性约束。
mysqld 启动失败时看到 ER_UNKNOWN_STORAGE_ENGINE 怎么办
这是最直接的信号：MySQL 8.0+ 在加载系统库时发现 mysql 库下仍有 MyISAM 表（比如残留的 mysql.plugin 或手动改过的 mysql.tables_priv），会直接拒绝启动，并报错：ER_UNKNOWN_STORAGE_ENGINE 或 MY-010929: Storage engine 'MyISAM' does not support system tables
- 这类错误不依赖客户端配置，也不是 SQL 层面的权限问题，而是服务器元数据校验失败
- 即使你用
SET GLOBAL default_storage_engine = MyISAM也无效，系统表引擎不由该变量控制 - 唯一修复路径是让
mysqld重新执行系统表升级流程
mysqld --upgrade=FORCE 是唯一可靠触发点
MySQL 8.0 已废弃 mysql_upgrade 工具，所有系统表转换逻辑都收归到服务启动阶段。但默认启动只会尝试一次，失败后静默跳过。
必须显式调用：
mysqld --datadir=/var/lib/mysql --upgrade=FORCE --user=mysql
- 不要加
&后台运行，等进程退出（通常 10–30 秒） - 成功日志里会出现类似
mysql.user table upgraded to InnoDB的明确记录 - 失败时不会报错，只在错误日志中写
Failed to upgrade table mysql.db或Could not open mysql.db
转换失败的三个高频原因
mysqld --upgrade=FORCE 看似简单，但实际卡住往往因为底层条件不满足：
- 权限不足：
mysql用户对整个datadir必须有读写权；SELinux 环境下还需执行restorecon -R /var/lib/mysql - 残留
.frm文件：MySQL 8.0已弃用.frm元数据文件，但若旧版本遗留了损坏或不匹配的/var/lib/mysql/mysql/*.frm，会导致解析中断；可备份后直接删掉 - 磁盘空间不够：转换过程需临时写入新表结构，
ibdata1扩容或tmpdir空间不足都会中断；检查df -h /var/lib/mysql和df -h $(dirname $(mktemp -u))
导入 dump 时遇到 Unknown storage engine 'MyISAM'
这说明你的 dump 文件里还带着 ENGINE=MyISAM 语句，而目标 MySQL 8.0 已将 MyISAM 引擎标记为 SUPPORT = NO（查 SHOW ENGINES 可确认）。
- 不要指望
mysqldump --compatible=mysql4解决，它不改引擎声明 - 正确做法是在导出前清空所有 MyISAM 表：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine = 'MyISAM'; - 再批量执行
ALTER TABLE your_table ENGINE = InnoDB;，注意全文索引和TEXT字段前缀长度可能需同步调整
真正麻烦的不是转换动作本身，而是那些没被 information_schema 统计到的“隐形”表——比如某些监控插件创建的 mysql.general_log（如果启用了日志表且未关闭），或者人为复制进来的 mysql 库文件。它们不会出现在常规查询里，却足以让 mysqld 启动校验链路彻底断裂。
