MySQL 升级异常主因是版本间隐性差异，需分层排查：先确认服务启动状态及错误日志，再验证连接与权限，接着检查 SQL 行为与执行计划变化，最后核对字符集、sql_mode 等配置兼容性。
MySQL 升级后出现异常，核心问题往往不是“升错了”，而是新旧版本在行为、配置、语法或兼容性上存在隐性差异。快速定位关键在分层排查：先确认服务是否真正跑起来，再看连接通不通，接着查 SQL 执行对不对，最后验数据和配置配不配。
确认 MySQL 服务是否正常启动
很多“异常”其实卡在第一步——数据库根本没起来。
- 执行 systemctl status mysqld（或 service mysql status）查看服务状态，注意是否有“active (running)”或 报错提示
- 检查错误日志，默认路径如 /var/log/mysqld.log 或 /usr/local/mysql/data/hostname.err，重点关注 ERROR 级别行
- 常见启动失败原因：配置文件 （my.cnf）含新版本已弃用参数（如 query_cache_type 在 8.0 中移除）、数据目录权限不对、 端口 被占（3306）、或数据文件损坏
验证客户端连接与权限是否有效
服务起来了，但应用连不上，大概率是连接层出了偏差。
- 用命令行直连测试：mysql -u root -p -h 127.0.0.1 -P 3306（显式指定 host 和 port，避免 socket 路径干扰）
- 若报错 ERROR 1045 (28000)：密码或认证插件变更（MySQL 8.0 默认用 caching_sha2_password，老驱动不兼容），需重置用户认证方式：
ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘your_password’; - 若报错 ERROR 2003：检查 防火墙、bind-address 配置（是否监听了 127.0.0.1 或 0.0.0.0）、以及客户端驱动版本（JDBC 需 8.0+ 驱动对接 MySQL 8.0）
检查 SQL 行为变化与执行计划偏移
升级后页面能打开、连接也通，但查询变慢、结果错乱或报语法错误，多因优化器逻辑或语法规则调整。
- 对慢或异常的 SQL 执行 EXPLAIN FORMAT=TRADITIONAL，对比升级前后的 type、key、Extra 字段，确认是否出现全表扫描、Using filesort 或索引未命中
- 检查是否触发了严格模式（STRICT_TRANS_TABLES 默认启用），导致插入截断、零日期等被拒绝；可在会话中临时关闭测试：SET sql_mode = ”;
- 留意函数变更：如 GROUP BY 在 5.7 后默认要求所有 SELECT 字段出现在 GROUP BY 中；utf8 别名已被移除，必须用 utf8mb4
核对配置项与字符集兼容性
配置不匹配常引发静默异常，比如 中文乱码、排序错乱、连接池频繁重建。
- 运行 SHOW VARIABLES LIKE ‘%character%’; 和 SHOW VARIABLES LIKE ‘%collation%’;，确保 character_set_server、collation_server 与表 / 连接一致（推荐统一为 utf8mb4 + utf8mb4_unicode_ci）
- 检查 sql_mode 是否新增了限制项（如 ONLY_FULL_GROUP_BY），可导出当前值并按需精简
- 确认 lower_case_table_names 设置是否与原环境一致（Linux 下该值为 0 时表名大小写敏感，升级后若改为 1 可能导致视图或存储过程找不到表）
