设置时间戳默认值后数据无法保存怎么排查_权限设置与回滚处理

MySQL 5.7+ 中 CURRENT_TIMESTAMP 默认值不生效，主因是 SQL mode（如 STRICT_TRANS_TABLES）导致隐式默认被拒绝，或 ORM 显式传 NULL 覆盖数据库逻辑，而非版本或语法错误。

MySQL 5.7+ 中 CURRENT_TIMESTAMP 默认值不生效的典型表现

你有没有遇到过这种情况？明明在表结构里为字段定义了 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，但插入数据时，要么直接报错 field 'update_time' doesn't ha ve a default value，要么字段里写进去一个诡异的 '0000-00-00 00:00:00'（尤其是在严格模式被关闭的环境下）。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• 环境差异陷阱：本地开发一切正常，一到线上 CentOS 7.4 + MySQL 5.7 的环境就失效。这通常不是你的SQL写错了，幕后黑手很可能是SQL mode或服务器配置。
• 框架“好心办坏事”：在Spring Boot的实体类里，如果你手动给 updateTime 字段赋了 null 或者干脆没初始化，像MyBatis这样的ORM框架，可能会在生成的SQL语句里显式传入一个 NULL，直接覆盖掉数据库自己那套默认值逻辑。
• 特殊操作遗漏：在使用 INSERT ... SELECT 或者进行批量插入时，某些数据库驱动或框架可能会忽略字段的默认行为，特别是当插入语句没有显式列出所有列的时候。

检查 sql_mode 是否禁用了时间戳自动填充

MySQL 5.7 之后，默认启用了 STRICT_TRANS_TABLES 和 NO_ZERO_DATE 等模式。但这里有个常见的误区：真正影响 CURRENT_TIMESTAMP 默认值生效的，并不是 NO_AUTO_VALUE_ON_ZERO（它其实不相关）。问题的关键在于，是否启用了像 TRADITIONAL 模式子集里的 STRICT_ALL_TABLES，或者因为缺少 ALLOW_INVALID_DATES 而导致日期解析失败。

• 第一步：查看当前模式。执行 SELECT @@sql_mode;，先确认结果里是否包含 NO_ENGINE_SUBSTITUTION（它本身不直接干扰时间戳，但常常和其他限制性模式一同出现）。
• 聚焦核心嫌疑：重点检查有没有 STRICT_TRANS_TABLES。这个模式会让MySQL拒绝那些没有提供值、又没有明确DEFAULT定义的字段（即隐式默认值）。但对于已经声明了 CURRENT_TIMESTAMP 默认值的字段，它本不该拦截——除非你的INSERT语句里，显式地写了 update_time = NULL。
• 快速验证法：可以临时执行 SET sql_mode = ''; 清空模式，然后重试插入操作。如果成功了，那基本可以断定是SQL模式在作祟。当然，生产环境可别长期这么干，正确的做法是定位到具体是哪个模式项冲突，然后针对性调整。

权限与回滚场景下时间戳被清空的真相

这里需要澄清一个普遍的误解：问题不是“权限不够导致无法写入”。真正的剧情往往发生在事务回滚之后——字段值被恢复到了初始状态。想象一下这个场景：你先执行了 INSERT，紧接着又对同一行数据执行了 UPDATE 操作，但 update_time 字段并没有出现在 UPDATE 的SET子句里，那么它自然不会被更新。如果这个事务中途回滚了，那么连最初的 INSERT 操作都没有真正落库，时间戳又从何谈起呢？

• 检查应用逻辑：看看你的代码是不是在insert之后立刻执行了update，但却漏掉了给 update_time 字段赋值。比如在JPA里，你可能只修改了 status 字段，而忘了设置 updateTime = LocalDateTime.now()。
• 确认权限配置：确保数据库用户对目标表同时拥有 INSERT 和 UPDATE 权限。缺少 UPDATE 权限时，ON UPDATE CURRENT_TIMESTAMP 这个特性是不会触发的，不过 INSERT 操作仍然可以依靠 DEFAULT 值正常进行。但问题在于，如果应用程序误判为“更新失败”并进行了重试，就可能会引发一系列混乱。
• 理解回滚本质：回滚本身并不会“清空时间戳”。更准确的过程是：你在事务内先 INSERT（此时 create_time 和 update_time 都被设为当前时间），然后 UPDATE 了其他字段但没动 update_time，最后事务回滚。结果是，整条记录就像没出现过一样，自然也就不存在所谓“被清空”的时间戳了。

MyBatis-Plus 或 JPA 场景下，自动填充和数据库默认值的冲突

当ORM框架的自动填充机制和数据库的默认值同时存在时，问题不在于“谁优先”，而在于“谁先出手”。如果ORM框架在拼接SQL语句时，把 update_time 当作一个普通字段，显式地传入了 NULL 或空值，那么数据库的 DEFAULT 机制就完全失效了。

• 检查框架配置：确认实体类中的 updateTime 字段是否被 @TableField(fill = FieldFill.INSERT_UPDATE) 正确标注，并且对应的 MetaObjectHandler 已经被Spring容器成功扫描和加载。
• 查看实际执行的SQL：这是最直接的诊断方法。打开日志，看看最终执行的INSERT语句里，是不是出现了 update_time = ? 并且参数绑定为 null。如果是，那毫无疑问是框架覆盖了数据库的逻辑。
• 解决方案二选一：要么关闭ORM的自动填充功能，完全依赖数据库的默认值（确保所有INSERT语句都不显式传递该字段）；要么关闭数据库表的 ON UPDATE CURRENT_TIMESTAMP 特性，只保留 DEFAULT CURRENT_TIMESTAMP，然后统一由ORM框架在update时注入时间。

最后，还有一个非常容易被忽略的版本细节：MySQL 5.6 及以前的版本，一张表里只允许有一个 CURRENT_TIMESTAMP 字段。从 5.6.5+ 开始虽然支持了多个，但有个顺序要求：第一个必须是 DEFAULT CURRENT_TIMESTAMP，第二个才能设为 ON UPDATE CURRENT_TIMESTAMP。如果你的建表顺序弄反了，或者使用了低版本的兼容语法，这个特性可能会静默降级，导致字段值变成0值时间戳。这一点在排查老系统或迁移数据时尤其需要注意。