MySQL中DATETIME自5.6+起支持ON UPDATE CURRENT_TIMESTAMP，但需显式声明DEFAULT与ON UPDATE子句；TIMESTAMP默认更积极，但受时区、2038年限制等约束，生产推荐用DATETIME并明确控制行为。
MySQL 中设置自动更新时间戳字段，核心在于 TIMESTAMP 或 DATETIME 类型配合 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP 子句——但行为差异很大，尤其在 MySQL 5.6、5.7 和 8.0+ 版本间容易出错。
为什么 TIMESTAMP 字段能自动更新而 DATETIME 不行？
MySQL 5.6 起才支持 DATETIME 的自动初始化和更新，但需显式声明；TIMESTAMP 则默认更“积极”：只要没显式赋值，就会触发自动填充。不过 TIMESTAMP 有 timezone 敏感、范围窄（1970–2038）等限制，生产环境建议优先用 DATETIME 并明确控制行为。
-
TIMESTAMP字段若未设NOT NULL，且插入NULL或省略该列，会自动设为当前时间 -
DATETIME在 5.6+ 支持DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，但必须显式写出两个子句，缺一不可 - 一个表里最多只能有一个
TIMESTAMP字段带CURRENT_TIMESTAMP默认值（MySQL 5.6），8.0+ 已放开限制
ON UPDATE CURRENT_TIMESTAMP 不生效的常见原因
最常踩的坑是字段定义漏写 DEFAULT 子句，或用了不兼容的 MySQL 版本。自动更新只对 UPDATE 语句中“未被显式修改”的字段生效——哪怕你写 UPDATE t SET name='x' WHERE id=1，只要没碰时间字段，它就会更新。
- MySQL 5.5 及更早版本不支持
ON UPDATE CURRENT_TIMESTAMP用于DATETIME - 字段定义写了
NOT NULL却没配DEFAULT，会导致建表失败（如updated_at DATETIME NOT NULL ON UPDATE CURRENT_TIMESTAMP是非法的） - 使用了
INSERT ... ON DUPLICATE KEY UPDATE时，ON UPDATE CURRENT_TIMESTAMP仍会触发，但要注意是否符合业务预期 - 显式给该字段赋值（哪怕赋的是
NOW()）会跳过自动更新逻辑
推荐的建表写法（MySQL 5.7+）
明确、安全、跨版本兼容性好。用 DATETIME 避免时区转换风险，显式声明所有行为：
CREATE TABLE example ( id INT PRIMARY KEY AUTO_INCREMENT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
-
created_at只初始化，不随更新变动 -
updated_at初始化 + 每次UPDATE时刷新（除非显式赋值） - 如果想让
created_at也支持自动初始化但禁止后续修改，就别加ON UPDATE—— 这是唯一可靠方式 - 避免用
TIMESTAMP做主时间字段，除非你清楚服务器时区配置且业务接受其 2038 年限制
真正麻烦的不是语法本身，而是不同 MySQL 小版本对 DEFAULT 和 ON UPDATE 的解析差异，以及 ORM（比如 Laravel Eloquent 或 Django ORM）可能绕过这些底层规则直接拼 SQL。上线前务必在目标环境验证建表语句和实际 UPDATE 行为。
