工作这么几年MySQL 的报错见过不少但有一种错看着特别“不科学”第一次碰上会让人愣好半天Field remark doesnt have a default value明明 SQL 语句里字段、值一一对得上语法也没问题凭什么报“没有默认值”我最早遇到这个错是在处理一张订单表的回调写入时前端传过来的数据里少了一个remark字段INSERT 语句里也就没带它。当时我的第一反应是“SQL 写错了”但反复核对字段名、表名、字段类型都没找出问题最后才发现根子在表结构上。这篇文章就把这条报错从根因到修复完整拆一遍顺便把排查链路整理出来希望大家下次遇到时能在五分钟内定位而不是像我当初那样对着屏幕怀疑人生。1. 一条看似“无缘无故”的报错实际是表结构约束在作怪1.1 具体报错场景还原这个错误最典型的出现场景是往一张已有表里执行 INSERT 或 UPDATE 时某个字段没有在语句中赋值而 MySQL 严格模式下又不允许它为空。举个我实际用过的例子CREATE TABLE user_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(64) NOT NULL, user_id INT NOT NULL, remark VARCHAR(255) NOT NULL, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 );注意这个remark字段NOT NULL但没有DEFAULT。接着执行INSERT INTO user_order (order_no, user_id, amount) VALUES (NO20240101, 1001, 199.00);如果 MySQL 处于默认的严格模式STRICT_TRANS_TABLES这条 SQL 会直接报错ERROR 1364 (HY000): Field remark doesnt have a default value而如果把sql_mode里的严格模式去掉同样的 INSERT 会变成“warning 插入空字符串”数据就悄悄写进去了。这个差别非常关键后面我会专门展开。还有一种常见情况是 UPDATE 语句触发同一错误比如UPDATE user_order SET amount amount * 0.9 WHERE order_no NO20240101;如果user_order上有个 UPDATE 触发器往另一张表插入记录时漏了某个 NOT NULL 字段一样会抛出这个错而且乍看之下和报错表完全对不上。这也是这条报错最容易坑人的地方——报错的表不一定是你正在操作的表。1.2 严格模式下 NOT NULL 字段的真实行为要理解这条报错先得接受一个事实MySQL 对“NULL”和“没有默认值”是两件事。前者是数据取值后者是表结构定义。NOT NULL约束只说明“这个字段不能存 NULL”但并没有告诉我们“如果 INSERT 没给值MySQL 该怎么办”。在没有显式DEFAULT值的情况下MySQL 有一套隐式默认值规则数值类型默认 0字符串类型默认空串日期时间类型默认对应零值如0000-00-00。但这套隐式默认值只在非严格模式下生效。一旦开启严格模式MySQL 的选择就变了——直接抛错把问题暴露给应用层而不是默默替你做主。说白了严格模式是为了防止“数据悄悄变成奇怪的值”。如果业务里允许 remark 为空你会希望它插入后是空字符串如果业务里不允许 remark 为空那这条 INSERT 本身就有问题。MySQL 没法替业务做决策所以严格模式下它选择“宁可报错也不猜”。提示这个报错和字段是不是主键没关系。主键如果是 AUTO_INCREMENT自增列本身有隐式生成规则不会踩这个坑但普通字段就不一样了。2. 根因拆解为什么 MySQL 会拒绝这条 INSERT 语句2.1 字段定义与隐式默认值规则先回到建表语句本身。一条完整的字段定义通常包含字段名、数据类型、是否允许 NULL、默认值、字符集等。例如remark VARCHAR(255) NOT NULL,这里没有写DEFAULT所以 MySQL 认为该字段“没有默认值”。此时如果 INSERT 语句没有包含这个字段MySQL 需要自己决定怎么处理。MySQL 官方的行为规则大致是这样字段有显式DEFAULT直接用默认值字段允许 NULL且没有给值就写入 NULL字段是NOT NULL且没有DEFAULT非严格模式使用类型的隐式默认值如字符串空串、数值 0严格模式直接报错拒绝写入。很多人建表时会忽略“要不要写 DEFAULT”觉得反正插入时都会带值。但表结构是给别人用的也是给未来的你用的——一旦应用代码里漏传字段这个问题就会以报错的形式冒出来。尤其在团队协作的项目里一张表的字段可能被多个服务同时写入A 服务传全了字段B 服务只传了部分字段那 B 服务就会成为这条报错的常客。2.2 sql_mode 中 STRICT_TRANS_TABLES 的作用机制sql_mode是 MySQL 服务端的一组会话级/全局级参数控制着很多行为其中和本条报错最相关的是STRICT_TRANS_TABLES和STRICT_ALL_TABLES。默认安装的 MySQL 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启用严格模式对非事务表如 MyISAM只在第一批数据出现错误时才报错允许部分写入。STRICT_ALL_TABLES则对所有表一律严格。在这个模式下MySQL 拒绝向“NOT NULL 且无默认值”的字段插入缺失值。如果没有这个模式MySQL 会悄悄把空字符串或 0 写进去只在 warning 日志里留一条记录。很多“数据看起来正常但后期统计对不上”的谜案往往就源于这种静默写入。比如金额字段缺省变成 0报表汇总时平白多了一批 0 元订单排查起来相当费劲。2.3 显式 DEFAULT 与隐式 DEFAULT 的差别很多人把DEFAULT NULL和“没有默认值”搞混。其实DEFAULT NULL只在字段允许 NULL 时合法意思就是“不写就存 NULL”DEFAULT 0/DEFAULT 显式默认值写入时未提供就用这个什么都不写且是NOT NULL没有默认值严格模式下报错。另外一个容易混淆的是“默认值表达式”。MySQL 8.0 支持函数式默认值例如create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,这就是显式默认值合法且常用。而create_time TIMESTAMP NOT NULL,同样是 NOT NULL 无默认值如果 INSERT 没写入严格模式一样会报Field create_time doesnt have a default value。这里要特别提醒TIMESTAMP在没有显式默认值的情况下MySQL 5.6 之前的旧版本会隐式给第一个 TIMESTAMP 字段加DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP容易让人误以为“时间字段不会报这个错”。到了 MySQL 8.0这种隐式规则已经变了时间字段同样会因为没有默认值而报错。所以看到时间字段报错时别惊讶直接按同一套流程排查。3. 诊断链路先从哪下手再查哪遇到报错最忌讳一上来就改 sql_mode 或给所有字段加 DEFAULT。不加判断的“一刀切”很可能掩盖真正的业务问题。我的排查顺序固定如下三步。3.1 第一步看表结构的正确姿势用SHOW CREATE TABLE而不是DESC来看表结构。为什么因为DESC只显示字段类型、NULL 与否、默认值而SHOW CREATE TABLE会完整展示索引、约束、默认值表达式一眼能看出哪个字段既 NOT NULL 又没有 DEFAULT。SHOW CREATE TABLE user_order\G重点关注NOT NULL且没有DEFAULT的字段。这些字段就是潜在的“报错点”。一次排查中我甚至发现连续两个字段都少写了 DEFAULT修复时要一起处理只补一个的话下一个报错马上会冒出来。3.2 第二步确认当前会话的 sql_modeSELECT SESSION.sql_mode; SELECT GLOBAL.sql_mode;确认严格模式是否开启。如果SESSION.sql_mode里没有STRICT_TRANS_TABLES那报错可能来自别处如果有再看是哪条 INSERT 漏了字段。有人会问为什么看会话级还要看全局级因为连接池里的连接可能各自有不同的会话设置。比如应用中某个连接执行过SET SESSION sql_mode 那么这个连接上的行为就和别的连接不同。排查线上问题时不光要看全局还要考虑到连接级差异。提示MyBatis、JDBC 连接池一般不会主动改 sql_mode但某些管理工具或脚本会在连接后执行 SET 语句导致同一库在不同连接下行为不一致。这也是“测试环境正常、生产环境报错”的常见来源之一。3.3 第三步复现最小化用例拿到有问题的表结构后我会复制一张最小表来复现CREATE TABLE tmp_order LIKE user_order; INSERT INTO tmp_order (order_no, user_id, amount) VALUES (T1, 1, 1.00);如果报错能复现说明问题在表结构本身如果复制表后没有报错那就要把注意力转向触发器和应用层的插入路径。这一步很关键因为触发器也可以给字段塞值表面看起来 INSERT 没问题实际是触发器里的逻辑碰到了同样约束。4. 修复方案三选一改表、改代码、还是调整 sql_mode这个问题没有“唯一正确解”只有“当前业务下最合适的解”。我通常按下面的顺序权衡。4.1 方案 A给字段补默认值这是最直接的修复方式也最推荐。ALTER TABLE user_order ALTER COLUMN remark SET DEFAULT ;如果某个字段本来就不该为空也可以设置一个有业务含义的默认值比如状态字段默认PENDING、数字字段默认0。在 MySQL 8.0 中还可以用表达式作为默认值ALTER TABLE user_order ALTER COLUMN create_time SET DEFAULT (CURRENT_TIMESTAMP);注意修改默认值不会重建整张表只是修改元数据执行速度一般很快。但有一个前提表里已有数据必须符合目标约束。比如你把一个字段从允许 NULL 改为 NOT NULL DEFAULT 0若表里已经有 NULLALTER 会失败或需要额外处理。执行前建议先备份或者至少确认业务影响-- 查看可能受影响的行 SELECT COUNT(*) FROM user_order WHERE remark IS NULL;4.2 方案 B修正 INSERT 语句或代码逻辑如果这个字段在业务上“必须有值”那么正确做法是改应用代码让 INSERT 无论如何都带上该字段而不是依赖数据库默认值兜底。比如 Java 侧的 MyBatis 中插入语句如果写成insert idinsertOrder parameterTypeOrder INSERT INTO user_order (order_no, user_id, amount) VALUES (#{orderNo}, #{userId}, #{amount}) /insert那remark没传时就会触发报错。修复应该是补齐字段insert idinsertOrder parameterTypeOrder INSERT INTO user_order (order_no, user_id, amount, remark) VALUES (#{orderNo}, #{userId}, #{amount}, #{remark}) /insert或者在应用层对空值做校验提前拦截。这种修复方式的好处是让“数据完整性”的语义留在应用逻辑里坏处是要动代码、发版。对于一两个字段的问题动代码有时候显得“重”但从数据质量角度考虑核心字段必须走这条路。4.3 方案 C调整 MySQL 的 sql_mode 策略很多人一遇到这个错就关严格模式。我觉得这需要谨慎。直接执行SET GLOBAL sql_mode ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION;把STRICT_TRANS_TABLES去掉确实能消除报错。但代价是以后所有“NOT NULL 无默认值”的插入都会静默写成空字符串或 0数据质量风险直线上升。对线上核心业务表我不建议这么做。有一种相对可控的折中方案只对某个会话调整。比如在应用连接初始化时SET SESSION sql_mode NO_ENGINE_SUBSTITUTION;这样只影响该连接不改变全局行为。但这要求你对业务很有把握知道这些静默值不会造成脏数据。4.4 各方案的适用场景与优缺点对比为了让大家一眼看清差异我整理了一个对比表修复方案适用场景优点缺点推荐度补 DEFAULT字段允许有业务默认值改动小、不涉及代码业务语义易被隐藏高改 INSERT/代码字段业务上必须有值数据完整性由应用保证需要发版高关掉严格模式临时救急、非核心库见效快脏数据风险大低会话级禁用严格模式局部任务、特定连接影响面小需应用改造连接中说实话我个人的实践原则是先补默认值排查完业务后再决定要不要改代码。如果这个字段只是日志、备注类的可选信息补默认值就够了如果是金额、状态这类核心字段那必须让应用显式传值否则后期查数时一个0会把你带到沟里去。5. 进阶场景触发器、存储过程与批量导入中的坑很多人以为把表和 INSERT 检查完就万事大吉但我在实际排障中至少三次遇到“源头不在 INSERT 本身”的情况。5.1 触发器中触发的不默认值报错MySQL 的触发器是在 INSERT/UPDATE/DELETE 前后自动执行的一组 SQL。如果触发器里对一张“NOT NULL 无默认值”的表执行了 INSERT或者给某个字段赋值时漏了字段报错也会从触发器里冒出来。举个例子用户表每次更新后要在审计表里记录日志CREATE TABLE user_audit ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, action VARCHAR(32) NOT NULL, detail VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TRIGGER trg_user_audit AFTER UPDATE ON user FOR EACH ROW BEGIN INSERT INTO user_audit (user_id, action) VALUES (NEW.id, UPDATE); END;这个触发器向detail字段没有赋值如果detail是 NOT NULL 且无默认值一个看似正常的 UPDATE 就会报ERROR 1364 (HY000): Field detail doesnt have a default value排查时如果只看应用层的 UPDATE 语句永远找不出问题。我建议每次遇到这个报错先顺手查一下相关表的触发器SHOW TRIGGERS LIKE user_audit;5.2 存储过程动态 SQL 里的隐藏炸弹存储过程里如果使用 PREPARE / EXECUTE 动态拼接 SQL字段列表是运行时才确定的非常容易出现“某些分支漏字段”的情况。更隐蔽的是存储过程中用了临时表临时表的结构继承了另一个表的 NOT NULL 约束而后续插入时又没带全字段。我的建议存储过程插入前先用一个显式变量补齐默认值SET remark IFNULL(p_remark, ); INSERT INTO user_order (order_no, user_id, amount, remark) VALUES (p_order_no, p_user_id, p_amount, remark);这样即使外部传入的存储过程参数为 NULL也能被应用层逻辑转化为业务认可的默认值而不是把锅甩给 MySQL 的隐式默认值。5.3 批量导入LOAD DATA / mysqldump时的 NULL 处理用LOAD DATA INFILE导入 CSV 时如果文件里某列为空字符串而表字段是 NOT NULL 且无默认值LOAD DATA 的行为和 INSERT 不一样空字符串会尝试写入但如果是\NNULL 的表示就可能触发报错。导入前先做数据清洗或者在 LOAD DATA 语句里指定缺失值替换LOAD DATA INFILE /tmp/orders.csv INTO TABLE user_order FIELDS TERMINATED BY , (order_no, user_id, amount, remark) SET order_no order_no, user_id user_id, amount amount, remark IFNULL(remark, );另外mysqldump导出的备份在导入新库时如果目标库的 sql_mode 更严格比如备份时非严格导入时严格也会出现类似报错。多环境同步时我会固定统一的 sql_mode 配置避免环境差异带来的各种奇怪问题。6. 防复发建议建表规范、工具习惯与排错清单走到这里该聊点“避免下次再犯”的东西。6.1 建表阶段的 DEFAULT 设计规范现在团队每次评审建表语句我都会要求三件事NOT NULL字段必须显式写DEFAULT允许为空的字段明确DEFAULT NULL还是干脆不加 NOT NULL时间字段尽量用DEFAULT CURRENT_TIMESTAMP避免历史数据时间缺失。这条规范的核心逻辑很简单不要依赖 MySQL 的隐式默认值它只该是个兜底不该成为日常依赖。只要表结构里所有 NOT NULL 字段都有显式 DEFAULT这个报错的概率几乎为零。6.2 排查这类报错的通用思路清单以后遇到Field xxx doesnt have a default value我建议按这个顺序过一遍SHOW CREATE TABLE看目标表找出所有 NOT NULL 且无 DEFAULT 的字段检查报错的 INSERT/UPDATE 语句是否遗漏了这些字段如果 INSERT/UPDATE 语句没遗漏继续查触发器、存储过程、事件查看当前会话和全局的 sql_mode确认是否是严格模式用最小化用例复现确认是表结构问题还是语句问题根据业务决定补默认值、改代码还是调整模式。这个清单看起来简单但能避免大部分无谓的折腾。尤其是在团队协作环境里别人建的表你接手时并不清楚每个字段的约束细节按这个清单走一遍基本能定位。6.3 我个人的实际教训最后分享一个我踩得比较深的坑。有一次因为赶项目我在一个核心表里设计了score INT NOT NULL当时想着“分数必须有值”结果漏写了 DEFAULT。上游数据偶尔会漏传这个字段刚开始测试环境没暴露因为测试环境的 sql_mode 被某位同事在全局改过严格模式被关掉了INSERT 一直静默写入 0。上线后生产环境是严格模式业务一跑就报错那叫一个手忙脚乱。后来我总结出一个非常重要的经验测试环境、预发环境、生产环境的 sql_mode 必须保持一致否则很多“环境差异”问题会被测试覆盖掉。当团队统一了 sql_mode 和建表规范这类错误其实可以完全避免。还有一个小技巧是在排查这类报错时把SHOW WARNINGS用起来。非严格模式下 MySQL 虽然不报错但会在 warning 里记录隐式默认值的替换行为。执行完 INSERT 后立刻查一下SHOW WARNINGS;如果看到类似“Data truncated”或者“Field xxx doesnt have a default value”的 warning说明当前的 SQL 在严格模式下一定会报错只是现在被静默处理了。用这个办法可以提前在测试环境揪出一批潜在问题而不是等生产环境炸了再救火。这篇内容从根因、诊断、修复到进阶场景都拆了一遍希望能帮到还在被这条报错折磨的朋友。如果你在排查中遇到了跟文中不太一样的表现很可能问题出在触发器或环境差异上按我上面的清单一步步来大多数情况下都能快速定位到那一两个隐藏字段。
