mysql 8.0升级后insert报错“field 'xxx' doesn't have a default value”是因默认启用strict_trans_tables等严格模式，需通过alter table补默认值或调整sql_mode兼容，不可简单清空。
MySQL 8.0 升级后 INSERT 报错 Field 'xxx' doesn't have a default value
这是最典型的 SQL Mode 兼容问题：MySQL 8.0 默认启用 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，而旧版（如 5.7）常运行在宽松模式下。一旦表字段定义为 NOT NULL 且无默认值，但 INSERT 语句又没显式提供该字段，就会直接报错。
实操建议：
- 临时绕过（仅调试用）：
SET SESSION sql_mode = '';—— 但会丢失所有校验，不推荐上线使用 - 精准修复（推荐）：查出触发错误的表和字段，用
ALTER TABLE补默认值或改可空，例如：ALTER TABLE user MODIFY COLUMN phone VARCHAR(20) DEFAULT ''; - 检查当前模式：
SELECT @@sql_mode;，重点关注是否含STRICT_TRANS_TABLES、NO_ZERO_IN_DATE、ERROR_FOR_DIVISION_BY_ZERO
如何安全降级 SQL Mode 以兼容老应用
不能简单清空 sql_mode，否则会打开危险缺口（比如插入非法日期、除零静默失败）。真正要做的，是保留必要校验，只关掉破坏兼容性的几项。
实操建议：
- 在
my.cnf的[mysqld]段落中设置：sql_mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"—— 这是 5.7 默认值，去掉了 8.0 新增的NO_ZERO_IN_DATE等 - 避免写死绝对路径：配置文件位置可能是
/etc/my.cnf、/etc/mysql/my.cnf或/usr/etc/my.cnf，先用mysql --help | grep "Default options"确认 - 修改后必须重启 MySQL：
systemctl restart mysqld（或mysqld_safe），仅 reload 不生效 - 验证是否生效：
SELECT @@global.sql_mode;，注意区分@@global和@@session
sql_mode 配置项在不同版本中的关键差异
MySQL 5.7 默认值不含 NO_ZERO_IN_DATE 和 NO_ZERO_DATE；8.0.11+ 默认开启，且 TRADITIONAL 别名已隐含更严格的规则。盲目复制旧配置可能漏掉新增限制。
实操建议：
- 不要依赖
TRADITIONAL：它在 8.0 中实际等价于STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL，比你想要的还严 - 注意
ONLY_FULL_GROUP_BY的行为变化：8.0 对非聚合字段的检测更严格，即使字段在GROUP BY中出现别名也未必放过 - 如果应用大量使用
0000-00-00日期，必须显式去掉NO_ZERO_DATE和NO_ZERO_IN_DATE，光关 strict 不够
为什么改了 my.cnf 还不生效？常见排查点
不是所有 MySQL 启动都读同一个配置文件，也不是所有客户端连接都会继承全局 mode——尤其当应用层（如 PHP PDO、Java JDBC）显式执行 SET SESSION sql_mode 时，会覆盖全局设置。
实操建议：
- 确认 MySQL 实际加载的配置：
mysql -u root -p -e "SELECT @@config_file;"（8.0.26+ 支持）或用mysqld --verbose --help | grep "Default options" - 检查是否有多个
!include或!includedir引入了其他配置，导致被后续文件覆盖 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）禁止修改
sql_mode，只能通过控制台参数模板调整，且需重启实例 - 连接建立后，应用代码里调用了
SET SESSION sql_mode = ...，那配置文件的 global 设置就完全失效了
SELECT 能跑，不代表 INSERT 或 UPDATE 就没问题；客户端连上时的 session mode，可能和你刚改完的 global 完全无关。
