企业官网建设流程全解析

凌晨两点半，正在准备上线一批新功能。代码写完，INSERT语句一执行，控制台直接抛出一行红字：

Field 'xxx' doesn't 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意，name和age都是NOT NULL，而且都没写DEFAULT。现在执行：

INSERT INTO `test_user` (`name`) VALUES ('老张');

在严格模式下，MySQL 会立刻报错，提示Field 'age' doesn't 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列显示NO，Default列又是空的，那这个字段就是导致报错的元凶。

另外还有一种情况容易被忽略：报错信息里的字段名可能只是第一个被拦下来的字段。如果一条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_mode=ONLY_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 doesn't 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还是被改过的状态。这就会导致“为什么明明线上配置是严格的，但这条数据能插进去”这种诡异的偶发问题。所以应急归应急，事后一定要把修改还原，或者让应用重启清空连接池。

四种方案对比如下：

4. 实战复盘：一个真实案例的完整排查过程

讲一个我实际处理过的案例。当时是给一个老系统做数据迁移，从 MySQL 5.5 迁移到 MySQL 8.0，数据库版本升级之后，系统开始密集报错，错误信息几乎是同一个模板：Field 'xxx' doesn't 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. 常见问题速查表与避坑清单

这个报错相关的坑，我整理了一个速查表，方便之后遇到直接对照。

这里再说几个实操中容易踩的细节。

第一，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 模式的理解深度。很多人第一反应是关掉严格模式，确实很痛快，但它就像把房子的烟雾报警器给拆了，报警是没了，安全也没了。把这次报错当成一次体检，排查清楚哪些字段设计得不合理，一步步整改，比单纯的“消报错”有价值得多。

最后再分享一个小技巧：如果下次再看到doesn't have a default value，先不用慌，用两分钟执行一遍SELECT @@SESSION.sql_mode，再看一眼SHOW CREATE TABLE里报错字段的约束，90% 的情况这两条命令就能定位到问题。剩下的，就是根据业务场景选择上面说的五种方案之一了。