MySQL 时间戳自动更新的那些“坑”与最佳实践
在数据库表里设置一个能自动记录更新时间的字段，听起来是个再基础不过的需求。但实际操作起来，你会发现ON UPDATE CURRENT_TIMESTAMP这个看似简单的语法，背后藏着不少需要留意的细节。今天，我们就来把这些细节掰开揉碎了讲清楚。
MySQL 中 ON UPDATE CURRENT_TIMESTAMP 的基本用法
想让一个字段在记录更新时自动刷新为当前时间，ON UPDATE CURRENT_TIMESTAMP确实是那把钥匙。但先别急着用，它有几个硬性前提：这个字段的类型必须是TIMESTAMP或DATETIME，而且，它不能是主键或唯一键的组成部分——除非你明确允许它为NULL，或者给它设置了默认值。
新手常犯的一个错误是，只给DATETIME字段加上ON UPDATE，却忘了同时指定DEFAULT CURRENT_TIMESTAMP。虽然从MySQL 5.6.5开始支持这种用法，但在更早的版本里，这会导致报错。所以，最稳妥、兼容性最好的做法，是把两者都显式声明出来：
CREATE TABLE example ( id INT PRIMARY KEY, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
为什么我的 updated_at 没有随 UPDATE 变化？
这大概是踩坑最多的地方了。原因其实很简单：如果你的UPDATE语句里显式地给这个时间戳字段赋了值，哪怕你赋的值就是它自己（比如updated_at=updated_at），MySQL也会认为你打算亲自控制这个字段，从而跳过自动更新机制。
UPDATE example SET name='foo', updated_at=updated_at WHERE id=1;
上面这行代码，就会让updated_at原地不动。记住几个关键点：
- 确保你的UPDATE语句里不要出现这个时间戳字段的名字。
- 如果业务逻辑要求你先保留旧值，再更新其他字段，那可能需要考虑改用触发器，或者在应用层手动赋值。
- 另外提一句，像
UPDATE ... SET col=col这种写法，在严格模式下可能会被优化掉，但它依然会抑制时间戳的自动更新。
TIMESTAMP 和 DATETIME 在自动更新上的关键差异
虽然两者都支持ON UPDATE CURRENT_TIMESTAMP，但它们的“脾气”可不太一样：
- 时区处理：
TIMESTAMP字段存入时会被转换为UTC时间，读取时再根据当前连接时区转换回来；而DATETIME则是“存什么，取什么”，没有时区转换这回事。 - 数量限制：在MySQL 5.6.5之前，一个表里最多只能有一个
TIMESTAMP列可以设置DEFAULT CURRENT_TIMESTAMP或ON UPDATE CURRENT_TIMESTAMP，限制更严。 - 版本兼容：
DATETIME类型是从MySQL 5.6.5版本才开始支持ON UPDATE的，旧版本只能用TIMESTAMP。
那么该怎么选？如果你的应用需要服务跨时区的用户，并且希望有一个统一的时间基准，TIMESTAMP通常是更好的选择。否则，追求直观和简单的话，DATETIME就够用了。
批量更新或 REPLACE INTO 场景下时间戳是否触发？
答案是肯定的。只要UPDATE语句实际修改了某一行（哪怕只改了一个字段），并且你没有显式地去设置那个时间戳字段，ON UPDATE CURRENT_TIMESTAMP就会生效。
但有几个特殊的场景需要特别注意：
REPLACE INTO：这个命令的本质是先DELETE再INSERT。所以，它触发的是DEFAULT CURRENT_TIMESTAMP（插入新行），而不是ON UPDATE。INSERT ... ON DUPLICATE KEY UPDATE：如果命中了重复键，走了UPDATE分支，那么会触发ON UPDATE；如果是INSERT分支，则触发DEFAULT。- 如果UPDATE的条件不匹配任何行（比如
WHERE 1=0），时间戳当然不会变——因为压根没更新任何记录。
最后，还有一个真正容易被忽略的冷知识：使用ALTER TABLE修改字段定义（比如加个注释）不会触发时间戳更新。但如果是MODIFY COLUMN去改变字段类型或约束，可能会隐式地重建表行，从而导致时间戳被意外重置。所以，别依赖这种边缘行为，更别在生产环境随意进行这类ALTER操作。
