TRAE-AI编程
从 MySQL 5.7 升到 8.0，最容易被坑的不是新功能用不好，而是默认行为悄悄变了：认证插件、字符集、sql_mode 都和旧版不同。本文先给结论，再逐个拆解三个最常见的升级后错误，并给出可复现的修复步骤。
很多团队升级完才发现问题：应用连不上库、中文变成乱码、一条原本能跑的 SQL 突然报错。这些都不是代码写错，而是 MySQL 8.0 把一些历史默认值改了。理解这些变更背后的「升级兼容性」逻辑，比记住单条报错更重要，因为同类行为变更还会出现在其他默认项上。
所谓升级兼容性，指的是「同样的SQL、同样的客户端，在 5.7 能跑，在 8.0 却表现不同」的那类差异。它们通常不报语法错误，而是静默地改变结果或连接行为，所以最难排查。下面用三个真实高频错误来说明。
先看结论
升级后出问题，优先按「认证插件 → 字符集 → sql_mode」的顺序排查。认证失败看 caching_sha2_password，乱码看 utf8mb4，语法或行为异常看 sql_mode。这三项是 8.0 与 5.7 差异最大、也最容易在升级当晚爆雷的地方。
一、最小场景与预期行为
假设你的应用一直用 5.7，驱动里写的是 jdbc:mysql://host:3306/db，升级到 8.0 后什么都不改。预期是「连接照旧、数据照旧」，但现实常常是「连不上」或「查出来乱码」。一个实用建议：升级前用 mysqldump 导出 5.7 的结构与数据，在 8.0 测试库先跑一轮回归，把连接、字符集、SQL 三类问题提前暴露，比上线后救火成本低得多。
明确这个预期很关键：升级 shouldn't change your data, but it does change defaults. 所以排查时要把「我的代码没动」这个前提先放一边，从 8.0 的默认值入手。迁移前建议先读 MySQL8 教程 的版本说明，对照默认值差异。
二、错误一：客户端连不上，报认证插件不对
这是升级后第一个爆雷点。MySQL 8.0 把默认认证插件从 mysql_native_password 改成了 caching_sha2_password。老版本的 JDBC、旧驱动、部分 ORM 不认识新插件，直接连接失败。
-- 查看当前用户的认证插件
SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';
如果你的 plugin 列是 caching_sha2_password，而驱动太旧，就会连不上。最稳的修复是升级驱动（MySQL Connector/J 8.0+ 原生支持），如果暂时不能升驱动，可以把该用户改回旧插件：
ALTER USER 'app_user'@'%'
IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;这里要强调升级兼容性：这不是你写错了密码，而是默认认证方式变了。关于默认认证的变更，官方文档有明确说明，建议升级前先核对驱动的兼容矩阵。补充一点：caching_sha2_password 成为默认是出于安全考虑，它比旧插件支持更现代的握手与缓存机制。所以改回旧插件只是临时兼容手段，长期仍应升级驱动以保留安全收益。
三、错误二：中文变成乱码，字符集默认变了
第二个常见坑是字符集。MySQL 8.0 把默认字符集从 latin1 改成了 utf8mb4，默认排序规则也变了。这本身是好事，但如果你的表是在 5.7 用 latin1 建的，升级后新建表用了 utf8mb4，而连接层、表、列的字符集不一致，就可能出现乱码或插入报错。
-- 查看库、表、列的字符集
SELECT DEFAULT_CHARACTER_SET_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = 'test_db';
SHOW FULL COLUMNS FROM users;
修复思路是统一字符集：库、表、连接三层都设为 utf8mb4。连接串里显式指定 characterEncoding=utf8mb4，新建对象时确认字符集一致。升级兼容性在这里的体现是：旧数据如果当初就以错误字符集存了，光改默认值是救不回来的，需要先确认存量数据的真实编码。字符集与排序规则的完整用法可查 MySQL 速查手册。另外 8.0 默认排序规则从 utf8mb4_general_ci 变为 utf8mb4_0900_ai_ci，字符串比较与排序行为可能与旧环境略有差异，跨版本做比对时要留意。
四、错误三：原来能跑的 SQL 突然报错，sql_mode 更严格
第三个坑最隐蔽。MySQL 8.0 的 sql_mode 默认包含了 ONLY_FULL_GROUP_BY，而 5.7 某些环境下没开。于是 SELECT a, b, MAX(c) FROM t GROUP BY a 这种「没把 b 放进 GROUP BY」的写法，在 8.0 直接报错，在 5.7 却能跑。
-- 查看当前 sql_mode
SELECT @@sql_mode;
修复有两种：要么改写 SQL，把 SELECT 里的非聚合列都加进 GROUP BY（推荐，符合规范）；要么临时放宽 sql_mode（不推荐长期使用，会掩盖数据口径问题）。升级兼容性在这里的本质是：8.0 默认更严格，把过去「能跑但语义不清」的写法拦下来了。从 5.7 迁到 8.0 的实操步骤可看 Mysql Migration 教程。除了 ONLY_FULL_GROUP_BY，8.0 还默认开启 STRICT_TRANS_TABLES 与 NO_ZERO_DATE，过去能插的非法日期、超长截断数据现在会直接报错，迁移老数据前要先清洗。
动手验证清单
升级后想确认自己没踩坑，可以按下面顺序验证：
- 安装/配置：准备一套 5.7 与 8.0 并存的测试环境，用相同数据导入。
- 运行：分别用旧驱动和新驱动连接 8.0，观察能否成功。
- 检查：执行
SELECT @@sql_mode与SELECT user, plugin确认默认值。 - 预期：新驱动应连上；旧驱动报认证插件错误。
- 验证：插入一条含中文的记录再读回，确认无乱码。
- 失败处理：连不上先查 plugin，乱码先查字符集三层一致性，GROUP BY 报错先查 sql_mode。
- 注意：以上命令在 MySQL 8.0 实测可用，升级兼容性差异以你实际版本为准，未在本机逐条执行。
常见问题
Q：升级到 8.0 后应用连不上，但密码没错怎么办？
优先怀疑默认认证插件变成了 caching_sha2_password。先查 mysql.user 表的 plugin 列，再决定升级驱动还是把用户改回 mysql_native_password。这是升级兼容性里最高频的连接类问题。
Q：为什么同样的 GROUP BY 在 5.7 能跑、8.0 报错？
因为 8.0 默认开启 ONLY_FULL_GROUP_BY，要求 SELECT 里的非聚合列都出现在 GROUP BY 中。这不是 bug，而是 8.0 对 sql_mode 更严格导致的升级兼容性差异。
Q：字符集乱码一定要重建表吗？
不一定。先确认库、表、连接三层字符集是否一致；若存量数据当初就以错误编码存入，需要先核实真实编码再做转码，单改默认值无法修复已乱码的数据。
总结
MySQL 8.0 的升级兼容性风险主要集中在三个默认行为变更：认证插件 caching_sha2_password、字符集 utf8mb4、以及更严格的 sql_mode。排查顺序建议是「认证 → 字符集 → sql_mode」，对应连接失败、乱码、SQL 报错三类现象。升级前先核对驱动与字符集，升级后按本文清单逐项验证，基本能避开绝大多数升级当晚的雷。
