MySQL 8.0升级常见问题及应对：严格模式需修复表结构默认值，认证插件需切换为mysql_native_password或更新驱动，字符集应统一为utf8mb4_0900_ai_ci，禁用原地升级改用逻辑迁移，并全面压测验证行为变更。
sql_mode 严格模式导致插入失败怎么办
MySQL 8.0 默认启用 STRICT_TRANS_TABLES，而很多 5.7 环境长期运行在宽松模式下（比如只设了 NO_ENGINE_SUBSTITUTION），升级后立刻报错：ERROR 1364 (HY000): Field doesn't have a default value 或 ERROR 1292 (22007): Incorrect datetime value。
这不是数据坏了，是校验变严了。临时绕过等于埋雷，真正要做的，是在升级前或升级后立即修复表结构：
- 查当前模式：
SELECT @@sql_mode; - 逐表检查
NOT NULL字段是否缺默认值：SHOW CREATE TABLE `t_name`; - 给缺失字段补默认值（例如）：
ALTER TABLE t ADD COLUMN c INT DEFAULT 0 NOT NULL; - 不建议用
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';长期掩盖问题——已有连接不会生效，且新连接仍可能踩坑
老客户端连不上：caching_sha2_password 是罪魁祸首
MySQL 8.0 把用户认证插件从 mysql_native_password 换成 caching_sha2_password，但 JDBC 5.x、PHP mysqli 扩展旧版、甚至某些 Navicat 版本根本不认这个新插件，直接报 Access denied for user。
别急着升级所有驱动，先让服务跑起来：
- 升级后立刻执行：
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pass'; - 确认改成功：
SELECT User, Host, plugin FROM mysql.user WHERE User = 'root'; - 如果必须用新插件，JDBC 连接串至少加两个参数：
?serverTimezone=UTC&allowPublicKeyRetrieval=true，且驱动版本不低于mysql-connector-java:8.0.28
字符集乱码、emoji 存不进去？utf8mb4_0900_ai_ci 在捣鬼
5.7 常用的 utf8 实际是 utf8mb3，8.0 默认全切到 utf8mb4，而且排序规则从 utf8mb4_general_ci 升级为更精准但也更严格的 utf8mb4_0900_ai_ci。直接用 mysqldump 导出再导入，中文可能被截断，emoji 直接变问号。
迁移时最稳的做法不是“调低配置”，而是统一升级认知和操作：
- 导出时显式指定字符集：
mysqldump --default-character-set=utf8mb4 -u root -p ... - 导入前确保目标库已设好：
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 检查表级字符集：
SHOW CREATE TABLE t;，若仍是utf8或utf8mb3，手动转换：ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
系统表升级失败、mysql_upgrade 报错？别硬上原地升级
mysql_upgrade 工具在 8.0.16+ 已废弃，原地升级（in-place）看似快，实则风险集中：InnoDB 系统表结构变更、数据字典重构、权限表重写，任何一环卡住都可能导致实例无法启动。
生产环境强烈建议放弃原地升级，改走逻辑迁移路径：
- 用
mysqlsh -- util checkForServerUpgrade先做兼容性扫描，它会报出保留字冲突（如表名叫rank）、MyISAM 表、废弃函数等真实拦路虎 - 提前把非 InnoDB 表转干净：
ALTER TABLE t ENGINE = InnoDB; - 备份必须含
--single-transaction --master-data=2，并验证可恢复——别等升级完才发现 dump 文件里有乱码或权限语句失效
真正麻烦的从来不是命令敲几行，而是那些没报错但悄悄变了行为的地方：比如 GROUP BY 不再隐式排序、JSON_EXTRACT 返回类型更严格、甚至 ZEROFILL 属性被忽略。这些细节，只有在你用真实业务 SQL 跑一遍压测时才会露出来。
