检查应用连接是否因认证插件失败
MySQL 8.0 默认使用 caching_sha2_password 插件，而老版本 Java 应用（如使用 MySQL Connector/J 5.1.x 或 6.0.x 早期版）默认不支持该插件，会报错：public Key Retrieval is not allowed 或直接连接拒绝。
验证时先确认应用使用的 JDBC 驱动版本：
- 5.1.47+ 支持但需显式启用：在连接 URL 加
?allowPublicKeyRetrieval=true&useSSL=false（仅测试环境，生产慎用） - 8.0.11+ 驱动默认兼容，但需确保
serverTimezone显式设置（如serverTimezone=UTC），否则可能抛java.time.DateTimeException - 若无法升级驱动，可在 MySQL 中为应用用户降级认证方式：
ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';
排查 SQL 模式变更引发的插入/更新失败
MySQL 8.0 默认启用严格模式（STRICT_TRANS_tableS），且移除了 NO_AUTO_CREATE_USER 等旧模式。常见表现是原来能插入的空字符串、超长字段、零日期现在报错：Data truncated for column 'xxx' 或 Invalid default value for 'xxx'。
快速验证建议：
- 查当前 SQL 模式：
select @@sql_mode;，对比升级前后差异 - 临时放宽模式（仅测试）：
SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';（去掉STRICT_TRANS_TABLES） - 重点检查应用中 INSERT/UPDATE 语句是否依赖隐式类型转换或默认值填充，尤其是 DATETIME 字段传空字符串、int 字段传 NULL 但列定义为
NOT NULL且无默认值
验证权限系统变更对运维脚本的影响
MySQL 8.0 重构了权限表结构，mysql.user 表移除了 Password 列，改用 authentication_string；同时 CREATE USER 和 GRANT 行为更严格——不再隐式创建用户，且必须分开执行。
运维类脚本容易出问题的地方：
- 旧脚本用
GRANT ... ON *.* TO 'u'@'h';自动建用户 → 升级后报错Operation CREATE USER failed，需拆成CREATE USER 'u'@'h' IDENTIFIED BY 'pwd';+GRANT ... - 备份恢复脚本若直接 mysqldump 出
mysql库，再导入 8.0 会失败（系统表结构不兼容），应避免 dump 系统库，或使用--skip-triggers --skip-routines过滤 - 应用若自行拼接
SHOW GRANTS FOR ...结果做权限校验，注意 8.0 返回格式中角色权限（ROLE）和动态权限（如BACKUP_ADMIN）可能新增，需适配解析逻辑
观察字符集与排序规则的隐式行为变化
MySQL 8.0 默认字符集从 latin1 改为 utf8mb4，默认排序规则变为 utf8mb4_0900_ai_ci。这会影响 ORDER BY、GROUP BY、索引匹配甚至 LIKE 查询结果。
典型风险点：
- 原用
utf8mb4_general_ci的索引，在 8.0 下仍可用，但新创建的表默认用utf8mb4_0900_ai_ci，若应用 SQL 依赖排序稳定性（如分页查询用ORDER BY name LIMIT 10），结果顺序可能微调 -
COLLATE未显式声明的字段，在 JOIN 或 WHERE 条件中若涉及不同 collation，可能触发隐式转换警告或性能下降（如using filesort） - 验证方法：对关键业务表执行
SHOW CREATE TABLE t;，确认CHARSET和COLLATE是否符合预期；对高频查询加EXPLAIN format=TRADITIONAL，检查是否有Using temporary; Using filesort
真正麻烦的不是语法报错，而是那些“看起来正常跑着，但数据排序变了、分页跳了、权限漏了”的静默偏差——这些得靠核心业务路径的真实流量回放或影子比对才能揪出来。