先停服务并杀净残留进程，再用--upgrade=FORCE触发内核级修复；若失败，则用干净实例导出mysql结构替换损坏目录，切勿直接--initialize-insecure初始化原datadir。
启动失败时看到 MY-010020 或 MY-010119 错误，先停服务再确认残留进程
这类错误（如 Data Dictionary initialization failed 或 Failed to find valid data directory）不是配置写错或端口冲突，而是系统库（mysql 数据库）结构与 MySQL 8.0 内核不匹配。第一步必须确保 mysqld 完全退出：
运行 ps aux | grep mysqld，若仍有进程残留，用 kill -9 杀净；
检查 /var/lib/mysql/ibdata1 是否被其他进程占用（如 backup 工具、监控 agent）；
临时注释掉 my.cnf 中所有 innodb_force_recovery 行——它会跳过字典校验，让升级流程直接失效。
别碰 mysql_upgrade，改用 --upgrade=FORCE 触发内核级修复
mysql_upgrade 在 8.0.16+ 已彻底移除，执行它只会报 command not found 或引发 Failed to open mysql.component table。真正有效的入口是 mysqld 自身的升级开关：
执行 mysqld --user=mysql --datadir=/var/lib/mysql --upgrade=FORCE；
观察日志输出：必须看到 Upgrading system tables 和 Finished upgrading system tables 才算成功；
该命令不重建数据文件，只校验并修正 mysql 库中表结构、字段类型、引擎类型（强制转为 InnoDB）、填充缺失字段（如 password_last_changed）；
完成后立即停止进程，再用正常方式启动（systemctl start mysqld），不要在 --upgrade=FORCE 进程还在跑时直接 systemctl 启动。
--upgrade=FORCE 失败后，用干净实例导出结构替换 mysql 目录
如果强制升级后仍报 Unknown column 'plugin' 或 Storage engine 'MyISAM' does not support system tables，说明 /var/lib/mysql/mysql/ 目录本身已损坏，不能靠参数修复：
启一个同版本干净实例：mysqld --initialize-insecure --datadir=/tmp/clean；
进该实例执行：mysqldump --no-data --skip-triggers --skip-routines mysql > mysql_struct.sql；
停故障实例，备份原 /var/lib/mysql/mysql/（如 mv mysql mysql_bak_20260615）；
用 mysql_struct.sql 重建新 mysql 目录（注意保留 ibdata1、ib_logfile*、undo_* 等全局文件，只替换 mysql/ 下的 .ibd 和 .sdi）；
切勿用 --initialize-insecure 直接初始化原 datadir——它会清空所有用户、角色、GTID、复制配置，且 root 密码重置为空。
修复后登录失败？立刻查 plugin 字段是否匹配
即使 mysql.user 表存在且字段齐全，root 用户仍可能因认证插件不兼容被拒绝：
启动成功后，用 mysql -u root -p --skip-grant-tables 进入（仅限本地、临时）；
执行：SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root';；
若 plugin 是 mysql_native_password 以外的值（如 caching_sha2_password），且客户端不支持，就需手动改回：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_pwd';；
这个字段错位比密码错更隐蔽，很多“连不上”问题根源在此，而不是网络或权限配置。
