在MySQL中，为TIMESTAMP字段设置默认值为当前时间，必须使用DEFAULT CURRENT_TIMESTAMP，这是唯一被官方认可的函数。当一张表存在多个TIMESTAMP字段时，需要显式声明每个字段的默认值或更新规则，其具体行为会受到MySQL版本和服务器时区设置的显著影响。
MySQL 中 TIMESTAMP 字段如何自动设为当前时间
在数据库设计中，若希望某个字段能自动记录数据创建或更新的时间戳，最常用的方法是为 TIMESTAMP 类型字段设置 DEFAULT 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+ 版本中支持，允许字段在更新时自动刷新时间戳）。created_at TIMESTAMP DEFAULT NOW()❌ 这将导致错误：Invalid default value for 'created_at'。- 更隐蔽的陷阱：如果为两个
TIMESTAMP字段都设置了DEFAULT CURRENT_TIMESTAMP，却没有为第二个字段添加ON UPDATE子句，那么第二个字段的默认值可能会被静默地转换为0000-00-00 00:00:00，或者直接报错，具体行为取决于服务器 SQL 模式的设置。
为什么不使用 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 CURRENT_TIMESTAMP自动更新。- 核心区别在于：
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 存储，查询时再从 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 模式配置以及服务器时区设置的不同而悄然变化。因此，在将表结构部署到生产环境前，务必在目标环境中执行一次 SHOW CREATE TABLE 命令，亲眼确认最终的字段定义是否与你编写的 DDL 语句完全一致。这一步简单的检查，能够帮助你规避许多意想不到的陷阱和错误。
