1. 从一条建表语句报错说起：问题到底卡在哪
第一次碰到这个报错的人，多半是在写建表语句或者改表结构的时候，敲下了类似create_time datetime default current_timestamp这样一行，然后被数据库当头一棒。报错信息五花八门，有的提示语法错误，有的提示默认值不合法，有的干脆告诉你这个版本不支持。明明在别的项目里见过这种写法，怎么到自己这儿就不行了？
这个问题的核心，其实不是current_timestamp这个函数本身有问题，而是datetime类型在不同数据库版本、不同 SQL 模式下，对默认值的支持规则完全不一样。很多人脑子里记的是某一种版本的写法，拿到另一种环境里直接套，自然就撞墙。尤其是 MySQL 从 5.5 到 5.6 再到 5.7、8.0，这条规则改过好几次，网上搜到的答案又新旧混杂，很容易把人带沟里。
我先把结论摆出来，方便你对号入座：在 MySQL 5.6.5 之前的版本里，datetime列根本不允许把current_timestamp作为默认值，只有timestamp类型可以，而且一张表里还限制只能有一个timestamp列自动初始化。从 5.6.5 开始，datetime才被允许使用current_timestamp作为默认值，但前提是你的环境没有开启某些严格的 SQL 模式，或者写法要符合规范。到了 5.7 和 8.0，规则进一步放宽，但explicit_defaults_for_timestamp这个参数的取值又会横插一脚，让行为变得微妙。
所以这篇内容适合谁看？如果你正在建表、改表时被这个默认值问题卡住，或者你维护的项目要在多个 MySQL 版本之间迁移，又或者你只是想把这块规则彻底搞清楚、以后不再靠搜索碰运气，那接下来的拆解应该能帮到你。我会把版本差异、SQL 模式、参数开关、报错原文对照、以及实际排查的完整链路都摊开讲，最后给几套可以直接抄的写法。
需要先说明一点：下面涉及的版本行为，是基于 MySQL 官方文档和大量实际环境验证总结出来的常见实践，不同发行版或云托管环境可能有细微差别，遇到具体报错时仍要以你手头环境的实际反馈为准。
2. datetime 与 timestamp 的默认值规则差异
2.1 为什么 timestamp 能自动填充而 datetime 曾经不行
要理解这个报错，得先搞清楚datetime和timestamp这两个类型在设计上的根本区别。它们存储的都是日期时间，但底层机制完全不同。
timestamp在 MySQL 里存储的是从 Unix 纪元（1970-01-01 00:00:00 UTC）到目标时间的秒数，占 4 个字节。因为它存的是"绝对时间点"，所以它天然和时区挂钩——写入时按当前会话时区转换，读取时再转回来。正因为这种"绝对时间"的语义，MySQL 很早就赋予了timestamp自动初始化和自动更新的能力，也就是default current_timestamp和on update current_timestamp这套组合拳。
datetime则不一样，它存的是"字面上的年月日时分秒"，占 8 个字节（5.6.4 之后支持小数秒会再多占），不带任何时区信息。你写进去2024-01-01 10:00:00，读出来就是2024-01-01 10:00:00，不管服务器在哪个时区。这种"字面值"的语义，在早期 MySQL 的设计里，被认为不适合自动填充——因为自动填充需要一个"当前时刻"的概念，而"当前时刻"是跟时区相关的，datetime又不存时区，逻辑上就有点拧巴。
所以历史上，MySQL 只允许timestamp玩自动初始化这一套，datetime只能老老实实给一个常量默认值，比如default '1970-01-01 00:00:00'。这就是为什么在老版本里写datetime default current_timestamp会直接报错。
2.2 5.6.5 这个分水岭到底改了什么
MySQL 5.6.5 是一个值得记住的版本号。从这个版本开始，官方放开了datetime使用current_timestamp作为默认值和自动更新的限制。也就是说，下面这种写法在 5.6.5 及以上是合法的：
create table t_demo ( id bigint primary key auto_increment, create_time datetime default current_timestamp, update_time datetime default current_timestamp on update current_timestamp );同时，一张表里允许多个列使用自动初始化，不再有"只能有一个 timestamp 自动列"的限制。这个改动对业务表设计影响很大——以前为了绕开限制，很多人被迫用timestamp存创建时间，结果踩到时区转换和 2038 年问题的坑；现在可以放心用datetime了。
但这里有个关键细节：5.6.5 放开的是"语法层面允许"，实际能不能生效还受 SQL 模式影响。如果你的环境开启了NO_ZERO_DATE之类的严格模式，某些边界写法仍然会报错。这一点后面会专门讲。
2.3 一张对照表看清版本行为
与其记一堆零散结论，不如直接看表。下面这张表把常见版本区间的行为整理出来，方便你快速定位自己处在哪一档：
| MySQL 版本区间 | datetime 能否用 current_timestamp 默认值 | 多列自动初始化 | 主要限制 |
|---|---|---|---|
| 5.6.5 之前 | 不允许，直接语法报错 | 不允许，仅一个 timestamp 列 | 只能用 timestamp 类型 |
| 5.6.5 至 5.7 | 允许 | 允许 | 受 SQL 模式与参数影响 |
| 5.7 及以上 | 允许 | 允许 | explicit_defaults_for_timestamp 影响 timestamp 行为 |
| 8.0 及以上 | 允许 | 允许 | 默认参数取值有变化，需注意兼容 |
看表的时候要注意，这里的"允许"指的是语法被接受，不代表任何配置下都能跑通。尤其是 5.7 之后引入的explicit_defaults_for_timestamp参数，它虽然名字里带 timestamp，但会间接影响你对整个默认值体系的理解，后面单独开一节讲。
2.4 一个容易被忽略的细节：小数秒精度
还有一个坑很多人没注意到：如果你给datetime指定了小数秒精度，比如datetime(3)，那么默认值写法也要跟着匹配。current_timestamp默认是秒级精度，如果你写datetime(3) default current_timestamp，某些版本会提示精度不匹配，需要写成current_timestamp(3)。
-- 精度不匹配，可能报错 create_time datetime(3) default current_timestamp; -- 精度匹配，推荐写法 create_time datetime(3) default current_timestamp(3);这个细节在 5.6.4 引入小数秒支持之后才出现，老项目迁移时特别容易踩。我见过有团队从 5.5 升级到 5.7，建表语句里一堆datetime(3)，结果默认值全写的current_timestamp，升级后批量报错，排查了半天才发现是精度没对齐。
3. 报错原文逐条对照：你遇到的是哪一种
3.1 语法错误类报错
最常见的一类报错长这样：
ERROR 1067 (42000): Invalid default value for 'create_time'或者：
ERROR 1064 (42000): You have an error in your SQL syntax ... near 'current_timestamp'1067这个错误码的意思是"默认值不合法"，通常出现在老版本（5.6.5 之前）用datetime配current_timestamp的场景，也可能是 SQL 模式导致的。1064则是纯语法错误，说明解析器根本没认出这个写法，多半是版本太老或者写法本身有拼写问题。
遇到1067，第一反应应该是查版本。执行select version();看一眼，如果低于 5.6.5，那基本就是版本不支持，别在语法上死磕了，换方案。如果版本够新还报1067，那就要往 SQL 模式方向查。
3.2 严格模式引发的默认值报错
另一类报错更隐蔽，往往出现在你自认为版本没问题的时候：
ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'create_time'这个报错表面上看跟current_timestamp没关系，但它经常和默认值问题纠缠在一起。原因是：当你开启了NO_ZERO_DATE或STRICT_TRANS_TABLES等严格模式，而表里某些datetime列的默认值被隐式设成了零值日期，插入数据时就会炸。
还有一种情况，你改表时想加一个datetime default current_timestamp的列，结果报：
ERROR 1067 (42000): Invalid default value for 'xxx'这时候如果版本是 5.7+，八成是因为sql_mode里包含了NO_ZERO_IN_DATE或NO_ZERO_DATE，而你的写法里某个环节触发了零值判断。解决办法要么调整写法，要么临时放宽模式（生产环境慎用）。
3.3 explicit_defaults_for_timestamp 带来的行为漂移
这个参数值得单独拎出来说。它的默认值在 5.7 和 8.0 之间变过：5.7 默认是OFF，8.0 默认是ON。它控制的是timestamp列的隐式默认行为，但会间接影响你对整个默认值体系的理解。
当它为OFF时，timestamp列如果没有显式指定默认值，会被隐式加上default current_timestamp on update current_timestamp，而且第一个timestamp列还会自动这样。当它为ON时，这种隐式行为被取消，timestamp列必须显式声明默认值，否则默认是NULL。
这跟datetime有什么关系？关系在于：很多人在datetime报错后，听人建议"改用 timestamp 就好了"，结果在 8.0 环境里改完发现行为又不对了——因为参数默认值变了，隐式规则不生效了。所以排查时一定要把这个参数的值查出来：
show variables like 'explicit_defaults_for_timestamp';看到ON还是OFF，再决定你的写法要不要显式声明。这个细节网上很多老文章没提，照着抄容易翻车。
3.4 云托管环境的额外变量
如果你用的是云厂商的托管数据库，还要多留个心眼。这类环境往往对sql_mode做了预设，有的默认就开了严格模式，有的对某些语法做了兼容性限制。同样的建表语句，在本地自建实例能跑，在托管实例就报错，这种情况我遇到过不止一次。
排查思路是：先在本地和托管环境分别执行select @@sql_mode;和select version();，把两个结果摆在一起对比。差异往往就藏在这两行输出里。别急着改语句，先搞清楚环境差异，否则改了半天可能只是碰巧绕过了某个模式限制，换个环境又炸。
4. 排查链路：从报错到定位的完整走法
4.1 第一步永远是确认版本和模式
很多人一看到报错就开始改 SQL，改来改去还是错，因为根本没定位到根因。我的习惯是，遇到这类默认值报错，先执行三条查询，把环境底牌摸清楚：
select version(); select @@sql_mode; show variables like 'explicit_defaults_for_timestamp';这三条分别告诉你：版本够不够新、严格模式开没开、timestamp 隐式规则是什么。三条结果一出来，问题基本能圈定范围。
举个实际的排查例子。某次同事反馈建表报1067，我让他先跑这三条。结果版本是 5.7.30，sql_mode里带着NO_ZERO_DATE,STRICT_TRANS_TABLES，explicit_defaults_for_timestamp是OFF。版本没问题，那问题就在模式上。再看他写的语句，datetime列用了default current_timestamp，但同一张表里还有个datetime列写了default '0000-00-00 00:00:00'。NO_ZERO_DATE一开，这个零值默认值就不合法了，报错自然指向它。把那个零值默认值改成NULL或者去掉，问题解决。
这个例子的启示是：报错指向的列，未必是真正出问题的列。1067有时会"嫁祸"，真正违规的可能是同表另一个列的默认值。所以排查时要把整张表的默认值都过一遍，别只盯着报错那一行。
4.2 用最小复现语句隔离问题
定位到大致方向后，下一步是构造最小复现。把出问题的列单独拎出来，建一张只有一两列的表，看还报不报错：
create table t_min ( id int primary key, create_time datetime default current_timestamp );如果这张最小表能建成功，说明问题不在这个写法本身，而在原表的其他部分（比如其他列的默认值、字符集、存储引擎等）。如果最小表也报错，那问题就锁定在这个写法加当前环境的组合上，继续往下查版本或模式。
这个"最小复现"的思路，是我处理所有数据库报错时的固定动作。它能快速把干扰项排除掉，避免在复杂的建表语句里大海捞针。尤其是那种几十个字段的大表，直接改原语句试错成本太高，不如先隔离。
4.3 逐步放开模式验证假设
如果你怀疑是sql_mode搞的鬼，可以临时把模式调宽松来验证。注意，这一步只在测试环境做，生产环境不要随便动全局模式：
-- 仅当前会话生效，安全 set session sql_mode = '';把会话模式清空后，再执行原来的建表语句。如果能成功，基本可以确认是某个模式项在作祟。然后逐项加回模式，二分定位到底是哪一项。常见嫌疑项是NO_ZERO_DATE、NO_ZERO_IN_DATE、STRICT_TRANS_TABLES。
验证完之后记得把会话模式恢复，或者直接断开重连，别让宽松模式影响后续操作。我见过有人在会话里清了模式，然后接着跑了一堆业务 SQL，结果数据质量出了问题，回头查半天才发现是模式被临时改了没恢复。
4.4 一张排查决策表
把上面的链路整理成一张表，遇到报错时按图索骥：
| 现象 | 优先怀疑 | 验证动作 | 处理方向 |
|---|---|---|---|
| 1067 且版本低于 5.6.5 | 版本不支持 | select version() | 改用 timestamp 或升级 |
| 1067 且版本较新 | SQL 模式或同表其他列 | 查 sql_mode，检查全表默认值 | 调整写法或模式 |
| 1064 语法错误 | 写法拼写或版本解析 | 最小复现 | 修正语法 |
| 1292 零值日期 | 严格模式 | 查 sql_mode | 去掉零值默认值 |
| 8.0 下 timestamp 行为异常 | explicit_defaults_for_timestamp | 查参数值 | 显式声明默认值 |
这张表不是万能的，但能覆盖八成以上的常见场景。真正排查时，还是要结合具体报错原文和环境输出，别硬套。
5. 可直接抄的写法与版本兼容策略
5.1 新项目推荐写法
如果你的项目跑在 5.7 或 8.0 上，没有历史包袱，直接用下面这套写法，清晰且行为可预期：
create table t_business ( id bigint unsigned primary key auto_increment, create_time datetime not null default current_timestamp comment '创建时间', update_time datetime not null default current_timestamp on update current_timestamp comment '更新时间' ) engine=InnoDB default charset=utf8mb4;几个要点说明一下。第一，显式写not null，避免默认值语义和 NULL 语义混淆。第二，create_time和update_time都用datetime，不用timestamp，规避时区转换和 2038 问题。第三，on update current_timestamp让更新时间自动维护，省去应用层手动赋值。第四，字符集和引擎显式声明，别依赖服务器默认值。
这套写法在 5.6.5 及以上都能跑，前提是sql_mode没有特别刁钻的限制。如果环境开了严格模式，这套写法本身也不违规，因为它没有涉及零值日期。
5.2 需要兼容老版本的降级方案
如果项目必须兼容 5.6.5 之前的版本，那datetime default current_timestamp这条路走不通，只能降级。常见方案有两种。
方案一，改用timestamp：
create_time timestamp not null default current_timestamp, update_time timestamp not null default current_timestamp on update current_timestamp代价是要接受时区转换行为和 2038 年上限。如果业务时间范围不会超过 2038，且能接受时区语义，这个方案最省事。
方案二，应用层赋值，数据库只给常量默认值：
create_time datetime not null default '1970-01-01 00:00:00'插入时由应用代码显式写入当前时间。这个方案把责任推给了应用层，数据库层面不依赖任何自动机制，兼容性最好，但要求所有写入路径都记得赋值，漏一处就出脏数据。我一般建议在 DAO 层统一封装，别让每个业务代码自己处理。
5.3 迁移场景下的双写过渡
如果是老系统升级，表结构不能一刀切改，可以考虑过渡期双列并存：保留老的timestamp列继续工作，新增datetime列逐步接管，应用层双写，观察一段时间后再下线老列。这样风险可控，出问题能快速回退。
-- 过渡期：老列保留，新列新增 create_time_ts timestamp not null default current_timestamp, create_time_dt datetime not null default current_timestamp双写期间要注意两列的一致性校验，可以定期跑对账 SQL，比对两列差值是否在容忍范围内。等确认新列稳定后，再改应用层读新列、删老列。这个套路在数据库迁移里很常见，核心思想就是"先并存、再切换、后清理"，别想着一步到位。
5.4 建表语句的检查清单
最后给一份建表前的自查清单，照着过一遍能避开大部分默认值坑：
- 确认目标环境版本，低于 5.6.5 就别用
datetime default current_timestamp。 - 确认
sql_mode，严格模式下避免零值日期默认值。 - 确认
explicit_defaults_for_timestamp取值，决定timestamp列要不要显式声明。 - 小数秒精度要和
current_timestamp(n)对齐。 - 显式写
not null，别依赖隐式行为。 - 字符集、引擎显式声明，别赌服务器默认值。
- 云托管环境单独验证，别拿本地结果直接上线。
这份清单看着琐碎，但每一条背后都是真实踩过的坑。尤其是版本和模式这两项，花三十秒查一下，能省掉半小时的瞎改。
6. 几个反直觉的实测经验
6.1 报错列不一定是问题列
前面提过1067会"嫁祸"，这里再强调一次。实测中遇到过一张表，报错指向update_time列，但真正违规的是create_time列的零值默认值。原因是 MySQL 解析默认值时按某种顺序校验，先撞上哪个报哪个，报错信息里的列名未必是根因所在。所以排查时要把整张表的默认值都扫一遍，别被报错列名带偏。
6.2 同样的语句在不同客户端结果不同
这个现象很迷惑人。有时候你在命令行客户端执行建表成功，换到图形化工具或者应用连接池里执行就报错。原因通常是不同客户端连接的会话sql_mode不一样，或者字符集设置不同。排查时要在报错的那个连接上查环境变量，而不是在另一个能跑通的连接上查。这个细节不注意，会得出完全错误的结论。
6.3 升级后老语句突然报错
版本升级后，原本能跑的建表语句突然报错，这种情况多半是sql_mode默认值变了。5.7 相比 5.6，默认sql_mode更严格，8.0 又进一步调整。升级前一定要把现有表的默认值写法过一遍，尤其是那些依赖宽松模式的零值默认值，提前改掉，别等升级完再救火。
6.4 参数改了但没生效
explicit_defaults_for_timestamp这类参数，有的是全局生效，有的需要重启，有的只影响新连接。改完之后如果行为没变，先确认改的是全局还是会话，再确认是否需要重连。我见过有人改了全局参数，但当前连接还是老会话，测了半天以为没生效，其实新开一个连接就正常了。
7. 收尾的一点个人体会
这块规则之所以让人头疼，根本原因是它横跨了版本、模式、参数三个维度，任何一个维度对不上，表现就不一样。网上搜到的答案往往只覆盖其中一个维度，照着抄自然容易翻车。我自己的习惯是，遇到这类问题先把环境三件套（版本、模式、参数）查清楚，再动手改语句，比盲目试错快得多。
另外，datetime和timestamp的选择，别只看默认值方不方便。时区语义、时间范围、存储空间这些因素都要一起考虑。默认值只是表象，底层语义才是决定长期维护成本的关键。把这块想清楚了，后面很多看似莫名其妙的报错，其实都能提前规避。
