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 写法，比一劳永逸地“降级模式”更可靠。
