必须用--upgrade=force强制触发内核级修复，因mysql_upgrade在8.0.16+已被移除，不参与数据字典重建；需确保mysqld干净退出、禁用innodb_force_recovery后执行该命令，成功标志为日志出现“upgrading system tables”和“finished upgrading system tables”。
MySQL 8.0 升级后因数据字典不兼容崩溃，根本不是配置写错或权限不足，而是 mysqld 启动时未能完成内核级元数据迁移——必须用 --upgrade=FORCE 让服务自己重走初始化流程，其他任何操作（删表、修日志、换配置）都无效。
为什么 mysql_upgrade 不能解决 Data Dictionary initialization failed
MySQL 8.0.16+ 已彻底移除 mysql_upgrade 命令。你执行它会报 command not found，或静默失败；强行用旧版调用 8.0 服务，反而触发 Table metadata is out of sync 或卡在 Failed to open mysql.component table。这不是工具没跑，是它压根不参与数据字典重建——只刷 INFORMATION_SCHEMA 缓存，而崩溃根源在 mysql 库底层结构与数据字典不匹配。
必须用 mysqld --upgrade=FORCE 强制重建系统表
这是唯一能触发内核级修复的操作，前提是进程干净、路径准确、配置无干扰：
- 先确保
mysqld完全退出：ps aux | grep mysqld无残留进程，systemctl is-active mysql返回inactive - 临时注释掉
my.cnf中的innodb_force_recovery（否则升级逻辑被跳过） - 用目标版本的
mysqld二进制执行：/usr/local/mysql-8.0/bin/mysqld --datadir=/var/lib/mysql --upgrade=FORCE --user=mysql - 紧盯错误日志，成功标志是出现
Upgrading system tables和Finished upgrading system tables - 一旦看到 “Finished”，立刻
kill该前台进程，再用正常方式启动：systemctl start mysql
常见卡点及对应动作
加了 --upgrade=FORCE 仍卡住，不是随机失败，而是明确的结构冲突信号：
-
[MY-010929] Storage engine 'MyISAM' does not support system tables→mysql目录下仍有 MyISAM 系统表（如columns_priv.frm），需清空/var/lib/mysql/mysql/后重试，或用同版本mysqld --initialize-insecure生成新系统库再导入权限 -
Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800→ 数据目录曾被更高版本 MySQL 写入（典型容器镜像版本倒挂），必须统一使用目标版本（如 8.0.42）启动 - 日志反复出现
Found partially upgraded DD→ 升级中途中断，残留不一致状态，不可重试；应备份后删除mysql/目录，再执行--upgrade=FORCE
最易被忽略的一点：--upgrade=FORCE 必须由目标版本的 mysqld 执行，Docker 用户尤其要注意容器内实际运行的是镜像自带二进制，而非挂载进来的旧版；路径写错、权限不对、磁盘空间不足（至少留 2GB），都会让升级停在 mysql.innodb_index_stats 这类表上，且不会报明显错误，只默默卡住。
