MySQL 版本不兼容问题，绝大多数不是“不能用”，而是
mysql_upgrade没跑、认证插件不匹配、系统表没刷新，或应用连接参数没同步更新。直接重装或硬降级反而容易丢数据。
mysql_upgrade 没执行或失败了
这是升级后服务能启但报错（如
ERROR 1267、
Unknown table 'mysql.plugin'）最常见原因。MySQL 8.0+ 不再自动触发升级逻辑，必须手动运行工具修复系统表结构。 先停服务：
sudo systemctl stop mysql再强制升级（尤其跨大版本时）：
sudo mysql_upgrade -u root -p --force如果提示
Failed to upgrade server或卡在某个表，说明系统库损坏，需备份后重新初始化：
sudo cp -r /var/lib/mysql /var/lib/mysql_backup<br>sudo rm -rf /var/lib/mysql/*<br>sudo mysqld --initialize-insecure --user=mysql（仅限 8.0+；5.7 用
--initialize）
客户端连不上：caching_sha2_password 认证失败
MySQL 8.0 默认改用
caching_sha2_password插件，但老程序（如旧版 Python
mysql-python、Java 5.x JDBC、某些 PHP 扩展）只认
mysql_native_password，连接时直接报
Authentication plugin 'caching_sha2_password' cannot be loaded。 临时解决（推荐测试环境）：
mysql -u root -p<br>ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';生产环境建议升级驱动：Python 改用
pymysql或
mysql-connector-python >= 8.0；Java 改用
mysql-connector-java 8.0.33+别在配置文件里加
default_authentication_plugin=mysql_native_password—— 这只是让新用户默认用旧插件，不影响已有用户，且 MySQL 8.4+ 已弃用该参数
应用启动失败：SQL 语法或字符集不兼容
比如 Seata 0.9.0、Django 2.x、旧版 Laravel 在 MySQL 8.0+ 上抛空指针或
Invalid default value for 'xxx'，本质是新版严格模式和默认字符集变了。 检查 SQL 模式：
SELECT @@sql_mode;若含
STRICT_TRANS_TABLES或
ONLY_FULL_GROUP_BY，可临时关闭（开发环境）：
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';字符集问题常表现为中文乱码或索引失效：确认连接 URL 含
characterEncoding=utf8mb4，且建表语句明确指定：
CREATE TABLE t (id INT) CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;大小写敏感性变更（
lower_case_table_names）必须在初始化时定死，升级中改会引发表找不到错误，别碰
降级或跨版本还原数据时出错
MySQL 不支持高版本数据目录直接扔进低版本服务里跑。比如把 8.0 的
/var/lib/mysql复制到 5.7 环境，服务根本起不来。 安全做法永远是导出 SQL：
mysqldump --all-databases --single-transaction --routines --triggers > backup.sql还原前先查目标版本限制：MySQL 5.7 无法识别 8.0 的 JSON 表达式语法、隐藏索引、角色权限等，dump 前加
--skip-routines --skip-triggers更稳妥 真要降级，走中间版本（5.7 → 8.0 → 5.7 不行；但 5.7 → 8.0 → 5.7 的 dump 再导入可以）
真正麻烦的从来不是命令敲不对，而是升级前没备份
/etc/mysql/my.cnf和
/var/lib/mysql，或者没在测试环境跑一遍全链路 SQL —— 一旦线上出问题，回滚比修复还慢。
