MySQL 升级后 sql_mode 变严格导致 SQL 报错是正常行为，需通过 SELECT @@sql_mode 确认问题，临时用 SET SESSION/GLOBAL 调整，永久修改配置文件，并推动代码层修复数据质量问题。
MySQL 升级后，sql_mode 默认值往往变严格（比如 5.7→8.0 后启用了 STRICT_TRANS_TABLES、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 等），导致原来能执行的 SQL 突然报错。这不是 bug，而是 MySQL 在强化数据安全与标准兼容性。关键不是“关掉它”，而是按需调整模式，兼顾兼容性与健壮性。
查看当前 sql_mode 设置
先确认问题是否真由 sql_mode 引起：
- 登录 MySQL，执行：
SELECT @@sql_mode; - 对比升级前后的输出（如旧版可能是
''或NO_ENGINE_SUBSTITUTION，新版常见STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION） - 查具体报错 SQL 的上下文，看是否涉及默认值插入、日期零值、除零、隐式类型转换 等
临时调整（开发 / 测试环境快速验证）
不改 配置文件，只对当前会话或全局生效，适合排查和过渡：
- 仅当前连接生效：
SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION'; - 对所有新连接生效（需有 SUPER 权限）：
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION'; - 注意：GLOBAL 设置在重启后失效；SESSION 设置不影响其他连接
永久修改配置（生产环境推荐方式）
编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段下明确指定 sql_mode：
- 若需最大兼容（不推荐长期用于新项目）：
sql_mode = "NO_ENGINE_SUBSTITUTION" - 若希望保留部分严格校验但绕过常见痛点：
sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_IN_DATE,NO_ZERO_DATE"
（去掉ERROR_FOR_DIVISION_BY_ZERO可避免除零报错，改为警告） - 修改后必须重启 MySQL：
sudo systemctl restart mysql（或对应服务名）
更可持续的处理思路
长期依赖宽松模式会掩盖数据质量问题。建议同步推进代码层修复：
- INSERT 中避免不写非空字段且无默认值——显式提供值或设 DEFAULT
- 避免插入
'0000-00-00'这类非法日期——用NULL或合法日期替代 - SQL 中做除法前加条件判断（如
WHERE divisor != 0），或用NULLIF(divisor, 0) - 应用层 ORM（如 MyBatis、Hibernate）检查是否生成了隐式类型转换语句
升级后的 sql_mode 变化是提醒你关注数据质量的一次契机。合理配置 + 逐步收敛 SQL 写法，比一劳永逸地“降级模式”更可靠。
