mysql 5.7 到 8.0 升级需重点应对默认行为变更：only_full_group_by 默认开启、caching_sha2_password 认证插件切换、utf8mb4 成为默认字符集及系统表结构重构，须提前检查兼容性并验证执行计划与权限。
MySQL 5.7 到 8.0 升级不是“一键替换”，核心卡点在默认行为变更
升级本身不难，但默认配置、SQL 模式、权限模型、字符集这几处一动就报错。很多团队卡在 mysql_upgrade 失败或应用连不上，其实根本不是工具问题，而是没提前清理掉 5.7 里“能跑但不合规”的写法。
必须检查的 4 类兼容性断裂点
MySQL 8.0 把很多“容忍型”逻辑改成了“严格型”，以下几类不处理，升级后服务大概率直接报错：
-
ONLY_FULL_GROUP_BY默认开启：原来SELECT a, b FROM t GROUP BY a这种漏掉非聚合字段b的语句会直接拒绝执行 - 密码认证插件从
mysql_native_password切到caching_sha2_password：老客户端（如某些 Python 2.x 驱动、旧版 Navicat）连不上，报错Client does not support authentication protocol requested by server -
utf8mb4成为默认字符集，且collation_server默认变成utf8mb4_0900_ai_ci：如果表/列显式指定了旧排序规则（如utf8mb4_unicode_ci），升级后可能触发隐式转换警告甚至索引失效 - 系统表结构变更：比如
mysql.user表删掉了Password字段，换成了authentication_string；权限视图重构成role_edges、default_roles等新表——依赖直接查mysql库的运维脚本会崩
升级前必须做的三件事
别急着跑 mysqld --upgrade，先确保这三项落地：
- 用
mysqlcheck --all-databases --check-upgrade扫描所有库，重点关注输出里的ERROR和WARNING行，尤其是提示 “requires upgrade” 或 “uses old password format” 的表和用户 - 把所有应用连接字符串里的
auth_plugin=mysql_native_password显式加上（哪怕当前是 5.7），避免升级后驱动自动协商失败；同时确认客户端版本支持caching_sha2_password（如 MySQL Connector/J 8.0.12+、PyMySQL 0.10.0+） - 备份时用
mysqldump --set-gtid-purged=OFF --skip-triggers（如果不用 GTID）或--set-gtid-purged=ON（如果用），别用物理备份直接拷 config 文件——8.0 的my.cnf里query_cache_type已废弃，硬塞进去会导致启动失败
升级后最常被忽略的验证动作
服务起来不等于升级成功。这几个点不验证，上线后可能半夜告警：
- 查
SELECT VERSION(), @@sql_mode;确认确实是 8.0.x 且ONLY_FULL_GROUP_BY在列表里；再跑一条带GROUP BY的旧 SQL，看是否真报错 - 用原应用账号连一次，执行
SELECT USER(), CURRENT_USER();，确认返回的用户身份和权限没变（8.0 的CURRENT_USER()对 role 的解析逻辑变了） - 检查慢日志里有没有新增的
Creating sort index或Using temporary; Using filesort：因为 8.0 的optimizer_switch默认启用了hash_join=on，某些关联查询计划可能倒退，得靠EXPLAIN FORMAT=TREE对比
字符集、权限、执行计划这三块没有银弹，只能按业务 SQL 样本实测。升级窗口期别只盯着“能不能启”，得盯“跑得对不对”。
