MySQL 8.0升级需聚焦业务卡点：collation变更致分页错乱、GROUP BY报错1055、权限模型不兼容；须显式指定COLLATE、补全聚合字段、升级JDBC驱动并重建用户，结合真实流量压测验证隐性逻辑。
业务团队不关心技术演进，只关心“升级会不会让功能出问题、上线要停多久、后续开发是不是更麻烦”。所以别讲SQL标准兼容性或InnoDB重构，直接从他们每天遇到的卡点切入——比如“为什么订单导出突然变慢”“为什么新上一个促销活动就报错500”。
MySQL 8.0 的默认排序规则（collation）变了，utf8mb4_0900_ai_ci 不再等价于 utf8mb4_unicode_ci
这是业务最常踩的坑：老系统用 utf8mb4_unicode_ci 建的表，升级后查询结果顺序突变，前端分页错乱、报表合计对不上。不是Bug，是规则更严格了——比如 “café” 和 “cafe” 在新规则下视为不同字符串，而旧规则会忽略重音符号。
- 改造点：所有
CREATE TABLE和ALTER TABLE ... CONVERT TO CHARACTER SET语句必须显式指定COLLATE utf8mb4_unicode_ci（如果业务逻辑依赖旧行为） - 验证方式：在测试库跑
SELECT * FROM orders ORDER BY title LIMIT 10，对比升级前后结果是否一致；特别注意含法语、西班牙语、中文拼音混合字段 - 风险提示：不改 collation 就上线，搜索框输入“zhang”可能搜不到“zhāng”，但错误日志里不会报错，只会静默返回空
GROUP BY 语义收紧，SELECT 中出现非聚合字段会直接报错
MySQL 5.7 允许 SELECT id, name, COUNT(*) FROM user GROUP BY id 这种写法（name 是非聚合字段），8.0 默认开启 sql_mode=ONLY_FULL_GROUP_BY 后直接拒绝执行。业务代码里大量存在的“偷懒写法”会在上线瞬间炸出一堆 1055 错误。
- 改造点：不是关
ONLY_FULL_GROUP_BY（治标不治本），而是补全SELECT列——要么加MAX(name)，要么把name加进GROUP BY - 排查命令：
SELECT * FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%GROUP BY%' AND TABLE_SCHEMA = 'your_db'，快速定位视图中的隐患 - 性能影响：补全聚合函数后，如果
name字段没索引，MAX(name)可能触发 filesort，需同步加索引
权限模型重构，mysql.user 表结构和 GRANT 语法不向下兼容
DBA 给业务方开账号时，以前用 GRANT SELECT ON db.* TO 'app'@'%' 就完事，现在会报错：“Account has no password, but password is required”。因为 8.0 强制要求密码强度策略，且 authentication_plugin 默认变成 caching_sha2_password，老版本 JDBC 驱动（如 mysql-connector-java 5.1.x）连不上。
- 改造点：应用侧必须升级 JDBC 驱动到 8.0+，并在连接串加
?serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=false - 账号迁移：用
mysqldump --no-create-info --skip-triggers mysql user导出用户数据，再用CREATE USER ... IDENTIFIED WITH mysql_native_password BY 'xxx'重建（避免插件不兼容） - 测试重点：灰度期间让业务查一遍“用户管理后台”的权限列表接口，这个接口通常直连
mysql.user表，最容易暴露字段缺失
真正难的不是改 SQL 或换驱动，是业务代码里那些没写注释的“临时绕过方案”——比如为规避 5.7 的子查询限制，硬写了个 JOIN 拼接两个聚合结果。这类逻辑在 8.0 下可能因优化器改写而失效，但单测覆盖不到，得靠真实流量压测才能暴露。升级前最好拉上业务方一起看一周慢查询日志，把“看起来奇怪但一直没报错”的 SQL 单独拎出来重审。
