凌晨两点半正在准备上线一批新功能。代码写完INSERT语句一执行控制台直接抛出一行红字Field xxx doesnt have a default value当时的心情怎么说呢不是崩是愣——这个报错看着明明白白但又感觉哪都不对劲。明明字段列表里都写了没写的字段为什么还要“默认值”这不是故意找茬吗。后来排查完才发现这根本不是 MySQL 在刁难谁而是它以一种非常“较真”的方式替我们把数据规范性问题给拦下来了。这篇博文就来完整复盘一下这个经典报错的成因、排查路径、解决方案和背后的设计逻辑希望能帮跟当时的我一样对着屏幕发愣的同学少走几小时的弯路。1. 先搞懂这个报错到底在说什么——从一次深夜上线说起先说结论这个报错背后的逻辑其实不复杂。它的核心意思是当你执行INSERT语句时MySQL 发现某条记录里有一个字段你在插入时没有显式给值而这个字段在表结构上又同时满足三个条件被定义成了NOT NULL非空约束没有设置默认值没有DEFAULT子句表的sql_mode中开启了“严格模式”主要是STRICT_TRANS_TABLES。只要这三个条件同时满足MySQL 就不会悄悄帮我们塞一个空字符串或者 0 进去而是直接报错把整条INSERT给拦下来。1.1 复现报错的三个必要条件为了方便理解我们直接在命令行里手动复现一遍。假设有一张简单的表CREATE TABLE test_user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL, age INT NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意name和age都是NOT NULL而且都没写DEFAULT。现在执行INSERT INTO test_user (name) VALUES (老张);在严格模式下MySQL 会立刻报错提示Field age doesnt have a default value。原因很简单这条插入语句只提供了name字段的值age字段天然就被 MySQL 当成“未提供值”处理。而age又是NOT NULL且没有默认值严格模式直接拒绝。如果把表结构改成age INT NOT NULL DEFAULT 0同样一条插入语句就能顺利执行MySQL 会替我们把age填成 0。所以这个报错实质上就是在执法一个规则凡是声明了“不能为空”的字段你必须要么给它一个默认值要么在每次插入时显式给它值。1.2 核心元凶sql_mode 的 STRICT_TRANS_TABLES真正让这个报错从“警告”变成“错误”的是sql_mode这个系统变量。在 MySQL 5.7 和 8.0 的默认配置里sql_mode包含了以下这些值ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION其中STRICT_TRANS_TABLES就是严格模式的开关之一。它的作用是对于支持事务的表比如 InnoDB一旦某条插入或更新语句的数据不合法直接抛错并回滚而不是像以前那样“睁一只眼闭一只眼”给个警告然后写入脏数据。MySQL 5.5 及更早的版本默认sql_mode是空的。那时候的默认行为是缺了值的NOT NULL字段如果字段类型是字符串就写成空字符串如果是数字就写成 0同时给你一条 warning。这种“温柔”的方式虽然不报错但很容易把脏数据悄悄写进库里等后面查数据的时候才发现问题那才是真正的灾难。所以从 5.7 开始MySQL 默认把严格模式开了起来。这个改动本身是好事问题在于很多老项目的表结构是按旧的宽松标准设计的代码也没考虑严格模式的存在一升级或者一换新环境就集体踩到这个报错上。2. 排查思路不要急着改表先按这条线走遇到这个报错第一反应肯定是去查是哪张表哪个字段出了问题。但如果只有报错信息没有具体字段名可以按下面这个顺序来定位效率会高很多。2.1 第一步确认当前会话和全局的 sql_mode先搞清楚 MySQL 到底处于什么模式。执行SELECT GLOBAL.sql_mode; SELECT SESSION.sql_mode;重点看STRICT_TRANS_TABLES在不在里面。如果在基本可以确定是这个模式在起作用。同时要注意GLOBAL和SESSION是有可能不一致的。有些开发环境会在连接池配置里单独设置会话的sql_mode有时候甚至只改了一个连接没有改全局。2.2 第二步定位具体是哪张表、哪个字段如果报错信息里带了字段名那就直接用下面这条 SQL 查看表结构SHOW CREATE TABLE 表名;或者DESC 表名;重点看报错提示的那个字段它旁边是不是有NO NULL注意DESC显示的是NO和DEFAULT列的值。如果Null列显示NODefault列又是空的那这个字段就是导致报错的元凶。另外还有一种情况容易被忽略报错信息里的字段名可能只是第一个被拦下来的字段。如果一条INSERT同时缺了多个字段的值MySQL 往往只报第一个遇到的字段修好一个之后再执行可能又报下一个。这种情况要有点耐心逐个清掉。2.3 第三步判断业务和代码层能不能接受默认值排查到最后一定会面临一个选择题这个字段到底该不该有默认值我的建议是先去看应用层的插入逻辑。拿用户表举例age字段如果业务上允许用户不填那就应该给一个默认值比如 0或者直接让这个字段允许NULL。如果业务上必须要有年龄信息那问题就不在表结构而在代码层没有把age字段传进来这是应用层的 bug应该去修INSERT语句而不是为了迁就代码去改表结构。很多新手一看到报错就想到ALTER TABLE加默认值这是治标不治本而且可能掩盖真正的业务逻辑漏洞。3. 五种解决方案与选型对比这个报错归根到底就两条路要么让字段“有默认值”要么让 MySQL“别管那么严”。根据不同的场景有五种常见的处理方案。3.1 方案A给字段设置合理的默认值推荐适用范围字段本身允许一个合理的默认语义比如统计类字段默认 0、状态类字段默认 1、日志类字段默认当前时间。操作方式ALTER TABLE test_user ALTER COLUMN age SET DEFAULT 0;这里提一个很多人踩过的坑ALTER COLUMN ... SET DEFAULT和MODIFY COLUMN是有区别的。前者只是添加或修改默认值不会动字段类型和注释后者是重建字段定义如果你在写MODIFY COLUMN时忘了把NOT NULL、COMMENT等属性带上可能会把这些属性意外改掉。-- 推荐这种写法只改默认值 ALTER TABLE test_user ALTER COLUMN age SET DEFAULT 0; -- 如果非要用 MODIFY务必把原有属性完整写出来 ALTER TABLE test_user MODIFY COLUMN age INT NOT NULL DEFAULT 0 COMMENT 用户年龄;方案A是最符合 MySQL 设计意图的做法也基本不影响正常写入性能推荐优先考虑。3.2 方案B修改 sql_mode去掉 STRICT_TRANS_TABLES适用范围老项目维护、历史遗留表结构短期无法全部整改、临时快速恢复业务。操作方式分为三个层级第一临时改当前会话SET SESSION sql_mode ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER;这个只对当前连接有效连接断开就失效。注意MySQL 8.0 里NO_AUTO_CREATE_USER已经被移除了如果是在 8.0 上直接用这个值反而会报错。更安全的做法是执行SET SESSION sql_mode ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION;说白了就是把原来那一长串值里的STRICT_TRANS_TABLES去掉其他保留。第二改全局配置SET GLOBAL sql_mode ...;这个会影响之后所有新建连接的会话但当前已存在的连接不会生效。第三配置文件持久化。在my.cnf或my.ini的[mysqld]段下加一行[mysqld] sql_modeONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION修改之后重启 MySQL 服务才会完全生效。这里要额外提醒方案B属于“治标”而且副作用不小。去掉严格模式之后插入空字符串、非法日期等操作又会变成“警告放行”脏数据会重新回到库里。这不是长久之计。3.3 方案C调整表结构允许字段为 NULL适用范围字段在业务上的确允许“未知”、“未填”状态。操作方式ALTER TABLE test_user MODIFY COLUMN age INT NULL DEFAULT NULL COMMENT 用户年龄;注意MySQL 里NULL和NOT NULL不仅仅是一个约束的问题它还影响索引的使用。比如在WHERE age 1这样的查询中如果字段允许NULL那么age IS NULL和age IS NOT NULL的查询条件跟age 1是无法完全等价的。而且NULL值在排序、聚合、COUNT等操作中的行为也很特殊容易造成线上统计数据的偏差。所以如果一个字段在业务上其实是不可能为空的不要因为图省事就把它改成允许NULL后续排查数据问题的时候你会付出更大的代价。3.4 方案D修改应用层 INSERT 语句显式补齐所有 NOT NULL 字段适用范围代码层确实漏传了字段值或者代码里写的是INSERT INTO t (a,b) VALUES (?,?)但表里有第三列c是NOT NULL且无默认值。这种场景下正确的做法是在INSERT语句里补上字段和值或者在 ORM 框架的实体映射里把字段加进去。很多人用 MyBatis 的时候容易遇到这种问题数据库表加了一个新字段但 XML 里的insert语句没有同步更新结果一执行就报Field doesnt have a default value。排查的方向就是打开数据库日志或者让 MyBatis 打印完整 SQL看看真实执行的字段列表里到底缺了哪个字段。3.5 方案E临时修改会话级 sql_mode 作为应急兜底适用范围线上正在告警业务不能停但表结构和代码都不是马上能改完。操作方式SET GLOBAL sql_mode TRADITIONAL;或者选择一个更稳妥的做法在当前数据库连接里用SET SESSION sql_mode临时改掉先让这个连接把活干完。这种方式最安全影响范围最小。但是这里有一个大坑要提醒如果是通过连接池访问数据库连接池里的连接是复用的。你在一段业务代码里SET SESSION改掉了sql_mode这个连接归还到连接池之后下次其他请求再拿到这个连接sql_mode还是被改过的状态。这就会导致“为什么明明线上配置是严格的但这条数据能插进去”这种诡异的偶发问题。所以应急归应急事后一定要把修改还原或者让应用重启清空连接池。四种方案对比如下方案影响范围副作用适用场景字段加默认值单表极小符合语义即可字段本身有合理默认值取消严格模式全局/实例大脏数据风险升高历史项目短期过度字段允许 NULL单表中影响聚合和查询语义字段确实允许未知补全 INSERT 字段应用代码极小代码漏传字段的场景4. 实战复盘一个真实案例的完整排查过程讲一个我实际处理过的案例。当时是给一个老系统做数据迁移从 MySQL 5.5 迁移到 MySQL 8.0数据库版本升级之后系统开始密集报错错误信息几乎是同一个模板Field xxx doesnt have a default value。当时的第一判断就是典型的“老库宽松模式、新库严格模式”冲突。5.5 默认没有STRICT_TRANS_TABLES当年建的表很多NOT NULL字段都没给默认值代码里也没刻意去填。原来靠 MySQL 自动填 0 和空字符串能撑过去升到 8.0 之后严格模式默认开启全部暴露。排查过程分了三步走。第一步统计所有含NOT NULL且无默认值字段的表。这里写了一个查information_schema的 SQL直接获取所有符合条件的字段SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, IS_NULLABLE, COLUMN_DEFAULT FROM information_schema.COLUMNS WHERE IS_NULLABLE NO AND COLUMN_DEFAULT IS NULL AND EXTRA NOT LIKE %auto_increment% AND TABLE_SCHEMA 目标库名 ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION;这个EXTRA NOT LIKE %auto_increment%条件很重要因为自增主键虽然是NOT NULL且COLUMN_DEFAULT为空但它不需要默认值如果不过滤掉会把一堆主键也列出来干扰判断。第二步人工审核这些字段。有些字段确实是业务漏了逻辑跟开发确认后在应用层补全了插入字段有些字段是历史遗留确实有无默认值的业务含义就统一加上DEFAULT值还有一些字段干脆就是冗余的属于老系统设计缺陷字段本身已经没有业务使用了加上了默认值。第三步验证最终效果。整改完成后把sql_mode维持在原样不取消严格模式然后跑了一整轮回归测试确认没有新的报错后才把流程推下去。这个案例给我最深的感触是报错本身只是表象真正要想清楚的是如何在不降低数据质量的前提下让系统平稳兼容新的模式。5. 常见问题速查表与避坑清单这个报错相关的坑我整理了一个速查表方便之后遇到直接对照。问题现象可能原因最快验证方式合理处理插入报 Field doesnt have default value严格模式下NOT NULL 无默认值字段缺值查看表结构确认字段约束补全插入字段或加默认值只有部分环境/连接报错连接池或会话级 sql_mode 不一致SELECT SESSION.sql_mode对比确认全局与连接池配置升级 MySQL 大版本后开始报错旧库无严格模式新库默认开启查历史版本 sql_mode 对比整改表结构不建议关闭严格模式插入 NULL 也报同样错误字段 NOT NULL 且插入值确实为 NULL检查代码传入的参数应用层校验空值加了 DEFAULT 0 还是报错ALTER TABLE 没真正生效SHOW CREATE TABLE确认重新执行修改语句TIMESTAMP 字段设置默认值失败旧版本不支持函数默认值查看版本和字段类型升级版本或改用代码赋值这里再说几个实操中容易踩的细节。第一MySQL 8.0.13 之前DEFAULT子句不支持表达式比如DEFAULT (CURRENT_DATE)这种写法会直接语法报错。如果需要在日期字段上设置默认值常用的替代方案是ALTER TABLE test_user MODIFY COLUMN create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间;这个写法对DATETIME和TIMESTAMP都适用。第二BLOB和TEXT类型不能有默认值这是 MySQL 的硬限制。如果报错字段是TEXT类型那抱歉这个字段不能通过加DEFAULT来解决问题。只能改为允许NULL或者在应用层保证每次插入都有值。第三如果字段是TIMESTAMP类型在旧版本里有可能因为explicit_defaults_for_timestamp参数导致的默认值行为不同。如果遇到TIMESTAMP相关的问题先查一下这个参数的值。第四也是最重要的一条修改sql_mode之前一定要先看当前的值用SELECT sql_mode先记录下来改完有问题再改回来。这个习惯救过我不少次。6. 如何从源头上避免这类报错说完了排查和解决方法最后聊一下怎么让这个报错从源头少出现。毕竟每次线上被它打乱部署节奏都是因为前期在设计或编码阶段埋下了隐患。6.1 建表阶段就做好规范约束新项目建表时不要把这个问题留给未来。我的习惯是所有NOT NULL字段必须跟着一个默认值。哪怕默认值是空的字符串也比没有强至少在严格模式下不会因为缺值直接报错。同时要在注释里写明这个默认值的含义避免后人来维护的时候猜来猜去。特别要注意的是DEFAULT值一定要符合字段的语义。比如一个手机号字段默认值写成 0 就不合理写空字符串勉强可以接受。如果字段上任何默认值都会产生歧义那就干脆做成允许NULL并且在业务层做空值判断。6.2 数据库变更要纳入评审流程很多线上事故都是因为一次“温和”的ALTER TABLE引起的。开发同学加了一个NOT NULL字段但忘了写DEFAULT结果代码一发布所有旧代码里的INSERT语句在这个新字段上缺值直接全量报错。所以在评审表结构变更时一定要加一条硬性检查新增的NOT NULL字段是否提供了DEFAULT。没有默认值的NOT NULL字段在上线前就要由开发去改代码补齐字段否则不允许发布。6.3 代码层统一使用显式字段插入写 SQL 的时候养成一个习惯INSERT INTO后面明确列出字段名不写INSERT INTO t VALUES (...)这种简写。显式字段插入的代码自解释性更强排查问题时能快速定位到到底插了哪些字段、漏了哪些字段。这一点在使用 ORM 框架时尤其重要MyBatis/JPA 的实体映射里新增字段后一定要同步更新 XML 或注解不能只在数据库层加列。6.4 对历史项目的长期改造建议老项目不能一次性大改的话可以先做一次摸底把information_schema的检查结果整理成清单分批次给字段补默认值。每次只改一部分表验证没问题再推下一批控制每批的变更风险。同时给每条变更配套一个回滚方案一旦线上出现异常能够快速撤回。我个人在实际操作中的体会是——这个报错看起来只是个约束错误但它真正考验的是对整个 MySQL 模式的理解深度。很多人第一反应是关掉严格模式确实很痛快但它就像把房子的烟雾报警器给拆了报警是没了安全也没了。把这次报错当成一次体检排查清楚哪些字段设计得不合理一步步整改比单纯的“消报错”有价值得多。最后再分享一个小技巧如果下次再看到doesnt have a default value先不用慌用两分钟执行一遍SELECT SESSION.sql_mode再看一眼SHOW CREATE TABLE里报错字段的约束90% 的情况这两条命令就能定位到问题。剩下的就是根据业务场景选择上面说的五种方案之一了。