my.cnf中sql_mode未生效的常见原因是配置位置错误（如写在[client]而非[mysqld]段）、被后续加载的配置覆盖、云数据库强制重置，或未重启服务；需用select @@global.sql_mode验证，而非仅依赖配置文件。
为什么改了my.cnf里的sql_mode却没生效
常见原因是配置写错位置或被覆盖。MySQL 启动时按顺序加载多个配置文件，后加载的会覆盖前面的；云数据库（如阿里云 RDS、腾讯云 CDB）还会强制重置全局 sql_mode，哪怕你配了也白搭。
实操建议：
- 确认配置在
[mysqld]段下，不是[client]或[mysql] - 运行
mysqld --verbose --help | grep "Default options"查实际加载路径 - 改完必须重启服务：
systemctl restart mysqld（reload不生效） - 验证是否生效：
SELECT @@global.sql_mode;，注意别查错作用域（@@session是当前连接，@@global才是全局）
如何安全绕过ONLY_FULL_GROUP_BY报错
错误信息里带 this is incompatible with sql_mode=only_full_group_by，说明你的 GROUP BY 查询选了非分组列且没用聚合函数包裹，比如 SELECT id, name FROM user GROUP BY dept_id。
不推荐直接删掉 ONLY_FULL_GROUP_BY —— 它暴露的是查询逻辑缺陷，关掉反而让结果不可靠。
实操建议：
- 重写 SQL：把
id、name加进GROUP BY，或改成MAX(name)等聚合表达式 - 真要“每组取一行”：用窗口函数更可控，例如
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY id)+ 外层过滤 - 若必须临时兼容：在配置中移除
ONLY_FULL_GROUP_BY，保留STRICT_TRANS_TABLES等必要校验项
Field 'xxx' doesn't have a default value 怎么修
这是 MySQL 5.7 升 8.0 最典型的 sql_mode 兼容问题，根本原因是 STRICT_TRANS_TABLES + NO_ZERO_DATE 同时启用，而老代码 INSERT 时漏写了 NOT NULL 字段，又没设默认值。
禁用严格模式只是掩耳盗铃，会让零日期、隐式截断等数据质量问题悄悄入库。
实操建议：
- 优先改表结构：
ALTER TABLE t MODIFY COLUMN phone VARCHAR(20) DEFAULT ''或设为NULL - 应用层补全 INSERT 字段，避免依赖隐式默认行为
- 若字段是时间类型且老项目用
'0000-00-00 00:00:00'占位，换成NULL或合法时间（如CURRENT_TIMESTAMP） - 临时调试可用
SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';，但上线前必须清理掉
云环境或容器里怎么动态调sql_mode
阿里云 RDS、腾讯云 CDB、Docker 官方镜像等场景下，你通常没有权限改 my.cnf 或执行 SET GLOBAL。硬改配置文件或重启服务不现实。
实操建议：
- JDBC 连接串末尾加参数：
?sessionVariables=sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'（MySQL Connector/J 8.0+ 支持） - PHP PDO 可在
connect()后立即执行：$pdo->exec("SET SESSION sql_mode = '...';"); - Docker 启动时用
--env MYSQL_INITDB_SQL_MODE=...（仅限初始化阶段） - 注意：所有会话级设置对已建立连接无效，必须在新连接建立时注入
@@global 是服务启动时读取的，@@session 是连接建立时继承的，而云厂商的管控层可能在连接握手阶段就重写了 session 值。别只信配置文件，得查实时生效值。
