mysql如何设置字段默认值为当前时间_使用Timestamp与CurrentTime

MySQL中TIMESTAMP字段自动设为当前时间需用DEFAULT CURRENT_TIMESTAMP，仅此函数合法；多字段时须显式声明，且受版本及时区影响。

MySQL 中 TIMESTAMP 字段如何自动设为当前时间

想让一个字段自动记录时间戳，最直接的想法就是用 TIMESTAMP 类型配合 CURRENT_TIMESTAMP 默认值。这思路没错，但魔鬼藏在细节里：在 MySQL 5.6.5 之前，一张表里只有第一个 TIMESTAMP 字段能用 CURRENT_TIMESTAMP 作默认值。新版本虽然放宽了限制，但依然需要你显式声明，别指望数据库会帮你“智能”处理。

新手最容易踩的坑，就是试图用 DEFAULT NOW() 或者 DEFAULT SYSDATE()。必须明确一点：在定义表结构（DDL）时，只有 CURRENT_TIMESTAMP（或者它的完整写法 CURRENT_TIMESTAMP()）才是被官方认可的默认时间表达式，其他函数一概不认。

• created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP 标准写法
• updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP （MySQL 5.6.5+ 支持多个 TIMESTAMP 字段自动更新）
• created_at TIMESTAMP DEFAULT NOW() 会直接报错：Invalid default value for 'created_at'
• 更隐蔽的坑：定义两个都带 DEFAULT CURRENT_TIMESTAMP 的 TIMESTAMP 字段，却没加 ON UPDATE —— 第二个字段的默认值可能会被静默转为 0000-00-00 00:00:00，或者直接报错，这完全取决于你服务器的 SQL mode 设置。

为什么不用 DATETIME 配 CURRENT_TIME

这里有个常见的概念混淆。CURRENT_TIME 返回的只是时间部分（HH:MM:SS），它根本不能用来给 DATETIME 或 TIMESTAMP 这类日期时间字段设置默认值。它只在运行时表达式里有效，比如 SELECT CURRENT_TIME。在 DDL 里设置默认值，CURRENT_TIMESTAMP 是唯一的选择。

再说说 DATETIME。在 MySQL 5.6.5 之前，DATETIME 字段完全不支持用函数作为默认值，默认值只能是常量。直到 MySQL 8.0.13 版本，它才支持 DEFAULT CURRENT_TIMESTAMP，但前提是需要将系统变量 explicit_defaults_for_timestamp 设为 OFF，而且它的行为（比如自动更新）和 TIMESTAMP 还不完全一样。

• DATETIME DEFAULT CURRENT_TIMESTAMP 在 MySQL 8.0.13+ 可用，但它不支持 ON UPDATE 自动更新。
• 核心区别在于：TIMESTAMP 存储的是 UTC 时间，查询时会根据连接时区转换；而 DATETIME 是“所见即所得”，存什么就查什么，不考虑时区。
• 所以，如果你的业务要求严格按服务器本地时间记录，且不希望涉及任何时区转换，那么用 DATETIME 类型，然后在应用层写入时间值，反而是更可控的方案。

ON UPDATE CURRENT_TIMESTAMP 的实际表现

这个子句的作用是，每当这行数据发生 UPDATE 操作时，字段会自动刷新为当前时间。但这里有个关键前提：该字段不能在 UPDATE 语句中被显式赋值。哪怕你给它赋的是 NULL 或者它原本的旧值，只要显式提到了它，自动更新就会失效。

另一个容易忽略的点是关于多个字段。如果一张表里有多个带 ON UPDATE CURRENT_TIMESTAMP 的 TIMESTAMP 字段，在旧版本里只有第一个定义的会生效。新版本（5.6.5+）允许多个，但你必须为每一个字段都写出完整的定义，不能偷懒省略。

• updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 完整定义，安全
• updated_at TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 没设置默认值，插入时如果没给值，可能就是 NULL（如果字段允许 NULL）或者直接报错。
• UPDATE t SET name='x' WHERE id=1 → updated_at 会自动更新。
• UPDATE t SET name='x', updated_at=updated_at WHERE id=1 → updated_at 不会更新，因为你已经显式地引用了它。

时区与初始化值的坑

TIMESTAMP 字段默认使用系统时区（system_time_zone）进行转换：存入时转为 UTC，查询时再转回本地时区。如果你的应用部署在不同时区的服务器上，却又依赖这些默认值进行时间比较或计算，结果很可能会让你大吃一惊。

还有一个典型问题源于 MySQL 的“隐式”行为。在建表时，如果你只写了 TIMESTAMP 却没指定 DEFAULT CURRENT_TIMESTAMP，当系统变量 explicit_defaults_for_timestamp=OFF（这是老版本的默认设置）时，MySQL 会偷偷给你加上这个默认值。这种行为在数据库迁移或主从复制时，很可能成为问题的根源。

• 检查当前设置：SELECT @@explicit_defaults_for_timestamp。如果返回 OFF，说明隐式规则在生效。
• 最安全的做法是：对所有 TIMESTAMP 字段都显式、完整地写出 DEFAULT 和 ON UPDATE 子句，绝不依赖任何隐式逻辑。
• 对于跨时区服务，业内常见的建议是统一用 UTC 时间存储，在应用层处理时区转换和展示，把主动权握在自己手里。

说到底，真正的麻烦往往不是语法怎么写，而是这些默认行为会随着 MySQL 版本、SQL mode、甚至服务器时区的不同而悄悄变化。所以，上线前务必在目标环境里执行一次 SHOW CREATE TABLE，亲眼确认字段定义是否和你写的一模一样，而不是你“以为”的那样。这一步检查，能帮你避开很多意想不到的坑。