MySQL升级看似只是换个安装包的事，实际操作中却经常踩坑。升级失败的原因五花八门：有的报Table 'mysql.user' doesn't exist，有的卡在[ERROR] InnoDB: Upgrade after a crash is not supported，还有的升级完成后客户端直接连不上了。这篇文章把MySQL升级中最常见的几类错误整理出来，逐个分析报错原因和解决方案，帮你把升级风险降到最低。
升级前必做的准备工作
先说结论：绝大多数升级事故都源于准备不充分。升级之前，务必确认升级路径是否受支持。MySQL官方规定只能从上一个稳定版本直接升级，比如升级到8.0需要从5.7升级，如果想从5.6升到8.0，就必须先升到5.7再升8.0，跨大版本直接跳跃是不被支持的。
第二件事是完整备份。这里强烈建议用mysqldump --single-transaction --all-databases做一份逻辑备份，同时用xtrabackup做一份物理备份。逻辑备份用于校验数据，物理备份用于快速回滚。备份完成后不要急着动手，先用mysqlcheck把所有表检查一遍：
# 检查所有数据库的表是否有损坏 mysqlcheck -u root -p --all-databases --check-upgrade # 只检查某个库 mysqlcheck -u root -p yourdb --check --extended
第三件事是关闭慢查询和未提交事务。升级前执行SET GLOBAL innodb_fast_shutdown = 1;（或者干脆用默认值1，最稳妥的是设为0做慢关闭），确保InnoDB做完整的purge和merge操作，然后正常关闭MySQL，避免升级后出现crash recovery相关的报错。
升级后启动失败的排查方法
升级完二进制文件，启动MySQL直接失败，这是最让人紧张的场面。此时不要慌，第一步永远是看错误日志。错误日志的位置在配置文件my.cnf的log-error参数中，如果没配置，默认在数据目录下，文件名一般是主机名.err。
常见报错有三种情况。第一种：[ERROR] InnoDB: Table mysql.innodb_table_stats not found，这是因为数据字典统计表在升级过程中没有正确更新，解决办法是进入MySQL后手动重建统计表：
-- 8.0.16之前的版本需要手动执行升级程序 -- 登录后先执行系统表升级 ALTER TABLE mysql.innodb_table_stats ENGINE=INNODB; -- 如果统计表损坏，可以先删掉存储过程再重建 DROP PROCEDURE mysql.drop_temp_table;
第二种：Upgrade after a crash is not supported，意思是上次MySQL不是正常关闭的，新版本拒绝在这种状态下升级。处理办法是用旧版本的二进制文件把实例正常启动一次，确认干净关闭后再换回新版本启动。这一步没法绕过，强行的结果只能是数据字典损坏。
第三种：日志中出现Failed to initialize DD Storage Engine或Data Dictionary initialization failed，通常是数据目录权限问题或者datadir指向了错误路径。用ls -l确认数据目录属主是mysql用户，同时检查磁盘空间是否耗尽——这个低级问题在实际案例中占比不低。
mysql_upgrade在8.0.16前后的差异
很多老DBA的习惯是升级二进制后立刻跑mysql_upgrade，但在8.0.16及之后的版本里，这个工具已经被移除了，继续执行会直接报command not found，这不是故障，而是机制变了。8.0.16开始，MySQL服务器在启动时会自动完成系统表和数据字典的升级检查，你只需要正常重启即可。
如果你用的是8.0.16之前的8.0小版本，仍然需要手动执行：
# 5.7 升级到 8.0.15 必须手动执行升级命令 mysql_upgrade -u root -p # 执行完查看输出，关注是否有 [ERROR] 行 # 升级后重启服务使变更生效 systemctl restart mysqld
需要注意，自动升级机制要求服务器以upgrade=AUTO模式启动（这是默认值）。如果之前有人在配置文件里设置了upgrade=NONE，新版本启动时会直接拒绝服务，日志里会有明确提示，把它改回AUTO或MINIMAL即可。另外升级过程可能耗时较长，大实例上看到启动卡住不要贸然kill进程，耐心等待日志输出结束。
升级后连接报错：认证插件问题
升级到8.0后，最经典的报错是客户端连接时抛出Client does not support authentication protocol requested by server; consider upgrading MySQL client。原因是8.0默认把密码认证插件从mysql_native_password换成了caching_sha2_password，老版本客户端和很多老驱动不支持这个新插件。
解决方案有两个方向。如果是应用侧短期无法升级驱动，可以把特定用户改回旧插件：
-- 将用户认证方式改回旧插件 ALTER USER 'appuser'@'192.168.1.%' IDENTIFIED WITH mysql_native_password BY 'YourPass123!'; -- 查看当前所有用户的认证插件 SELECT user, host, plugin FROM mysql.user;
更推荐的做法是升级客户端驱动到支持caching_sha2_password的版本，因为旧插件在后续版本中会被彻底移除，迟早要面对。另一个容易忽略的坑：8.0默认字符集变成了utf8mb4，排序规则变成utf8mb4_0900_ai_ci，如果应用里有硬编码的utf8_general_ci比较逻辑，可能出现排序结果不一致或报错Unknown collation。处理办法是在my.cnf中显式声明兼容配置，或者批量修改表的字符集。
升级失败的回滚方案
任何升级都要有退路。物理升级（in-place升级）虽然快，但有一个硬性限制：升级一旦完成并正常启动过新版本，就不能直接用旧版本二进制启动这个数据目录了，因为数据字典格式已经变化。所以回滚必须依赖升级前的备份。
推荐的操作流程是：升级前用xtrabackup做物理备份，如果升级失败，停掉新版本，清空数据目录，用备份恢复，再用旧版本启动，全程可以在一小时内完成。如果是主从架构，更稳妥的策略是先升级从库，观察几天业务指标正常，再做主从切换，把旧主库作为天然回滚点。这种滚动升级方式在生产环境被广泛采用，风险最低。
最后提醒一点：升级完成后不要只看服务是否启动，还要做完整验证——业务核心表的增删改查、定时任务、备份脚本、监控采集，都要跑一遍。很多隐患在升级当下不暴露，过几天才爆发，提前验证能省掉大量善后工作。