MySQL 8.0升级后系统表空间损坏主因是启动时自动升级失败，而非未运行已移除的mysql_upgrade；常见原因包括残留MyISAM系统表、跨版本跳升、--skip-grant-tables误操作等，应使用--upgrade=FORCE触发内核级修复。
MySQL 8.0 升级后系统表空间损坏，不是“没跑 mysql_upgrade”导致的——这个命令在 8.0.16+ 已被彻底移除，执行它只会报 command not found 或引发元数据冲突。真正的问题是：mysqld 启动时没能完成自动升级流程，或系统库残留了不兼容结构。
为什么 mysql_upgrade 无效还可能让问题更糟
你看到 SELECT * FROM mysql.user 报 Unknown column 'password_last_changed'，或 SHOW GRANTS 返回空，并非工具漏跑，而是系统表结构根本没被更新。强行从旧版本拷贝 mysql_upgrade 并运行，极大概率触发：
Failed to open mysql.component tableData Dictionary initialization failed-
mysql.user中plugin字段丢失，导致 root 用户认证失败
这些都不是权限或配置问题，是内核级元数据不一致，mysql_upgrade 已不具备修复能力。
启动时自动升级失败的真实原因
MySQL 8.0 要求所有系统表（mysql.user、mysql.db 等）必须为 InnoDB 引擎，且字段结构与新版本严格匹配。常见卡点包括：
- 错误日志出现
[MY-010929] Storage engine 'MyISAM' does not support system tables→ 说明mysql库中仍有 MyISAM 表（如mysql.columns_priv），这是直接覆盖安装或未清空旧/var/lib/mysql/mysql/目录所致 - 升级前用
--skip-grant-tables启动后执行了DROP TABLE或TRUNCATE→ 系统表被删但未重建 - 从 5.7 跨大版本直升 8.0（如跳过 8.0.22），部分字典转换逻辑缺失
用 --upgrade=FORCE 手动触发内部升级
这不是重装，是让 mysqld 重新走一遍数据字典校验与转换流程。操作前必须：
- 确认
mysqld进程已完全退出：ps aux | grep mysqld无残留 - 临时注释掉 my.cnf 中的
innodb_force_recovery（否则升级会被跳过） - 执行：
mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE
观察错误日志，成功会有 Upgrading system tables 和 Finished upgrading system tables 记录。完成后立即停进程，再用正常方式启动（如 systemctl start mysqld）。
系统表结构仍异常？优先导出干净结构替换
若 --upgrade=FORCE 后仍报字段缺失或引擎错误，说明 mysql 目录本身已损坏。此时不该用 --initialize-insecure（它会清空所有用户、角色、GTID、复制配置），而应：
- 启一个同版本干净实例：
mysqld --initialize-insecure --datadir=/tmp/clean - 导出结构：
mysqldump --no-data --skip-triggers --skip-routines mysql > mysql_struct.sql - 停故障实例，将该 SQL 替换原
/var/lib/mysql/mysql/下的表定义（保留ibdata1、日志文件及所有.ibd）
最易被忽略的一点：云厂商预装镜像或自定义初始化脚本，可能覆盖了 8.0 首次启动的自动升级逻辑——这种情况下，连 --upgrade=FORCE 都可能被绕过，必须检查启动日志里是否真有 Upgrading system tables 出现。
