最常见原因是字段定义漏了DEFAULT CURRENT_TIMESTAMP或误用DATETIME类型；TIMESTAMP更可靠，且需确保UPDATE语句实际修改了其他字段值才会触发自动更新。
为什么 ON UPDATE CURRENT_TIMESTAMP 不生效
最常见的情况是字段定义里漏了 DEFAULT CURRENT_TIMESTAMP，或者用了 DATETIME 类型。MySQL 要求 TIMESTAMP（或 DATETIME 从 5.6.5+）才能支持自动更新，但 TIMESTAMP 更可靠，尤其在时区处理上。另外，如果表里已有数据且该字段为 NULL 或空值，后续更新可能不会触发自动更新——因为 MySQL 只对显式修改的行、且字段本身参与了 UPDATE 语句才会触发（除非设了 ON UPDATE）。
实操建议：
- 建表时明确用
TIMESTAMP，并同时声明DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 避免给该字段手动赋值（比如写
SET updated_at = NOW()），否则会覆盖自动逻辑 - 如果字段已存在，用
ALTER TABLE ... MODIFY COLUMN重定义，不能只用CHANGE或漏掉DEFAULT
TIMESTAMP 和 DATETIME 在自动更新上的关键区别
TIMESTAMP 存储的是 UTC 时间，读取时按当前会话时区转换；DATETIME 则原样存储、原样返回，不涉及时区转换。这意味着：如果你的应用部署在多个时区，或 DBA 会切换会话时区，TIMESTAMP 的自动更新值更一致；但如果你依赖字面时间做日志比对、或和外部系统（如 Java 的 LocalDateTime）直接交互，DATETIME 可能更直观。
注意：MySQL 5.6.5 之前，只有 TIMESTAMP 支持 ON UPDATE；5.6.5+ 起 DATETIME 也支持，但默认不启用自动初始化，必须显式写 DEFAULT CURRENT_TIMESTAMP 才行。
实操建议：
- 新项目优先选
TIMESTAMP，尤其涉及跨时区或需要自动同步修改时间的场景 - 若必须用
DATETIME，确认 MySQL 版本 ≥ 5.6.5，并完整写：updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 不要混用：比如
created_at DATETIME DEFAULT CURRENT_TIMESTAMP+updated_at TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，容易因时区导致两个字段“看起来”不一致
更新时没变？检查是否真的触发了 UPDATE 语句
MySQL 只有在执行了实际字段变更的 UPDATE 语句时，才会触发 ON UPDATE CURRENT_TIMESTAMP。如果 UPDATE 的 SET 子句里没包含该字段，且其他字段值也没变（比如 WHERE id=1 匹配到行，但所有 SET 值和原值完全一样），InnoDB 可能跳过行更新，也就不会更新 updated_at。
实操建议：
- 测试时用
SELECT确认原值，再执行带明确变化的UPDATE，例如：UPDATE users SET name='newname' WHERE id=1 - 避免无意义更新，比如
UPDATE users SET status=status WHERE id=1—— 这不会触发ON UPDATE - 如需强制刷新
updated_at，可显式设置：UPDATE users SET status='active', updated_at=NOW() WHERE id=1，但这绕过了自动机制，要慎用
迁移旧表时如何安全添加自动更新时间字段
给已有数据的表加 TIMESTAMP 字段并启用自动更新，最容易出错的是默认值冲突。如果表里已有百万行，又没指定 NOT NULL，MySQL 会要求你提供默认值（哪怕只是 CURRENT_TIMESTAMP），否则报错 Invalid default value for 'updated_at'。
实操建议：
- 先关闭严格模式临时生效：
SET SQL_MODE='';（仅会话级，操作完可恢复） - 用
ALTER TABLE t ADD COLUMN updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 如果字段允许
NULL，必须显式写DEFAULT NULL，但这样ON UPDATE仍有效 —— 只是首次插入时为NULL，之后每次更新才设为当前时间 - 上线前在测试库跑一遍
UPDATE验证，确保应用层 ORM（如 Laravel Eloquent、Django ORM）没对这个字段做硬编码赋值
真正麻烦的不是语法，而是字段行为和业务逻辑的耦合：比如软删除标记更新、状态机流转是否该触发 updated_at、批量更新时要不要保留原始时间。这些没法靠数据库自动解决，得在应用层统一约定。
