SELECT @@sql_mode 返回一长串值但看不出问题，是因为需逐项比对新增模式（如NO_ZERO_IN_DATE、ERROR_FOR_DIVISION_BY_ZERO等），而非仅关注STRICT_TRANS_TABLES；云数据库常禁用SET GLOBAL，须通过控制台修改；配置失效多因路径错误或被覆盖，应确认实际加载的my.cnf位置并重启服务验证。
SELECT @@sql_mode 为什么看不出问题？
直接执行 SELECT @@sql_mode; 返回一长串值，但你可能根本不知道哪一项在作祟。常见误导是只盯着 STRICT_TRANS_TABLES 或 ONLY_FULL_GROUP_BY，却忽略它们的组合效应——比如 NO_ZERO_DATE 和 NO_ZERO_IN_DATE 同时启用时，连 '0000-00-00' 这种旧 dump 里的零日期都会被拒，而报错信息里根本不会提“日期”二字。
实操建议：
- 先用
SELECT @@sql_mode;拿到当前值，再和升级前备份的值逐项比对（别只看有没有 STRICT） - 重点筛查新增项：
NO_ZERO_IN_DATE、ERROR_FOR_DIVISION_BY_ZERO、STRICT_ALL_TABLES（8.0.11+ 默认新增） - 若用的是云数据库（如阿里云 RDS、腾讯云 CDB），
SET GLOBAL sql_mode往往被禁用，必须走控制台或 API 修改，不能只改配置文件
my.cnf 里写了 sql_mode 却没生效？
配置写对了，重启也做了，SELECT @@global.sql_mode 还是老样子——大概率是配置加载路径错了，或者被更高优先级配置覆盖。
实操建议：
- 运行
mysql --help | grep "Default options"确认 MySQL 实际读取的配置文件路径，常见位置有/etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf，不是所有系统都用/etc/my.cnf - 检查是否多个配置文件同时存在，
[mysqld]段落在不同文件里重复定义，后加载的会覆盖前一个 - 修改后必须用
sudo systemctl restart mysqld（或对应服务名），systemctl reload mysqld不会重载sql_mode - 验证是否生效：用新连接执行
SELECT @@global.sql_mode;，不要只查@@session，它可能被应用代码或连接池覆盖
INSERT 报错 “Field 'xxx' doesn't have a default value” 怎么修？
这不是配置问题，是表结构 + 应用 SQL 共同暴露的数据质量缺陷。8.0 的 STRICT_TRANS_TABLES 只是把原来隐式容忍的行为显式拦截了。
实操建议：
- 别急着关严格模式——先查出具体哪张表、哪个字段触发：
SHOW CREATE TABLE table_name;，看NOT NULL字段是否缺DEFAULT - 补默认值最稳妥：
ALTER TABLE user MODIFY COLUMN phone VARCHAR(20) DEFAULT '';或ALTER TABLE order ADD COLUMN status TINYINT DEFAULT 0; - 如果字段本就该允许空，改结构比降级模式更干净：
ALTER TABLE log MODIFY COLUMN remark TEXT NULL; - 临时绕过仅限调试：
SET SESSION sql_mode = 'ONLY_FULL_GROUP_BY,NO_ENGINE_SUBSTITUTION';（去掉 STRICT 相关项），但上线前必须回归修复
GROUP BY 报错 “Expression #1 of SELECT list is not in GROUP BY clause”
错误码 1055 的本质不是语法错，是 MySQL 在告诉你：这条查询逻辑上不明确——比如 SELECT id, name FROM user GROUP BY dept_id，同一部门有多人，id 和 name 到底该返回哪一行？
实操建议：
- 重写查询才是正解：
SELECT MAX(id), dept_id, MAX(name) FROM user GROUP BY dept_id;或用窗口函数取每组首行 - 若用 ORM（如 MyBatis），检查 XML/注解里是否生成了非标准 GROUP BY，有些老版本 mapper 会漏掉聚合包裹
- 临时删
ONLY_FULL_GROUP_BY能跑通，但掩盖了业务逻辑歧义，上线后可能返回随机数据 - 注意：MySQL 5.7.5+ 默认启用此项，8.0 不会退回去，靠配置“兼容”只是拖延技术债
ERROR_FOR_DIVISION_BY_ZERO，除零操作就静默变 NULL，下游计算可能全错；而保留它，就得在 SQL 里提前加 WHERE divisor != 0 或用 NULLIF(divisor, 0)。真正要花时间的，从来不是改配置，而是厘清这些边界在哪里。 
