SQL如何实现数据更新时自动维护LastModified时间戳

mysql用on update current_timestamp最轻量可靠，需注意timestamp默认约束限制；postgresql需触发器或generated列；sql server须显式赋值或触发器；跨库应统一存utc时间戳并禁用orm自动时间戳。

sql如何实现数据更新时自动维护lastmodified时间戳_统一时间格式

MySQL中用ON UPDATE CURRENT_TIMESTAMP自动更新时间戳

MySQL原生支持在字段定义时添加ON UPDATE CURRENT_TIMESTAMP，只要该行被UPDATE（哪怕其他字段没变），就会自动刷新这个TIMESTAMP或DATETIME字段。这是最轻量、最可靠的方式，无需触发器或应用层干预。

常见错误是把字段类型设为TIMESTAMP却没加NOT NULL，导致插入NULL时触发隐式默认值覆盖；或者误用CURRENT_TIMESTAMP作为默认值又加了ON UPDATE，结果插入和更新都改时间——这通常不是想要的行为。

推荐写法：last_modified TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
若需兼容微秒级，用TIMESTAMP(6)并确保MySQL ≥ 5.6.4
注意：一个表里最多只能有一个TIMESTAMP字段能用CURRENT_TIMESTAMP做默认值或更新值（MySQL 5.6以前限制更严）
DATETIME类型从MySQL 5.6.5起也支持ON UPDATE CURRENT_TIMESTAMP，但不自动转换时区，适合需要UTC存储的场景

PostgreSQL中用GENERATED ALWAYS AS (now())或触发器

PostgreSQL不支持MySQL式的ON UPDATE语法，必须显式处理。最干净的做法是用GENERATED ALWAYS AS (now()) STORED（PG 12+），但仅适用于计算列且不能被UPDATE直接修改；更通用的是用触发器。

容易踩的坑是触发器函数里用NOW()而不是CURRENT_TIMESTAMP——二者在事务内行为一致，但NOW()是别名，可读性稍差；更大的问题是忘记在触发器中判断是否真有字段变更，导致无意义地更新last_modified，干扰MVCC版本判断。

安全写法：触发器函数内先比较OLD.*和NEW.*（排除last_modified字段），仅当有差异才赋值NEW.last_modified := CURRENT_TIMESTAMP
若用GENERATED列，需确保应用层从不向该字段写入值，否则报错
时区统一靠SET timezone = 'UTC'或建表时用TIMESTAMP WITH TIME ZONE，避免依赖客户端时区

SQL Server里靠DEFAULT约束 + UPDATE语句显式赋值

SQL Server没有自动更新时间戳的内置机制（ROWVERSION是二进制版本号，不是时间戳）。必须靠DEFAULT GETDATE()配合UPDATE时显式设置，或用AFTER UPDATE触发器。

最常被忽略的是：很多人给last_modified加了DEFAULT GETDATE()，却在UPDATE语句里完全不提这个字段，结果它永远停在插入时刻。SQL Server不会像MySQL那样“悄悄更新”。

推荐做法：所有UPDATE语句末尾统一加上, last_modified = GETDATE()
若无法控制所有SQL（如ORM生成），则必须用触发器，并注意触发器里用GETUTCDATE()而非GETDATE()来保证UTC一致性
DATETIME2(3)比DATETIME精度更高、范围更大、时区无关，应作为首选类型

跨数据库统一时间格式的关键点

所谓“统一时间格式”，本质是统一时区基准和精度表达，不是字符串格式。应用层看到的"2024-03-15T14:22:08Z"只是展示层转换，数据库内部应始终存UTC时间戳。

最容易被绕过的细节是ORM框架（如Hibernate、TypeORM）的自动时间戳行为：它们可能用自己的逻辑覆盖数据库原生能力，比如Hibernate的@UpdateTimestamp会拦截SQL，导致MySQL的ON UPDATE失效；而TypeORM的@UpdateDateColumn默认用new Date()，受应用服务器时钟影响。