UPDATE语句中应显式用数据库时间函数（如NOW()）设置updated_at字段，避免字符串拼接或触发器依赖；MySQL可用ON UPDATE CURRENT_TIMESTAMP自动维护，PostgreSQL需触发器，ORM批量更新须手动赋值。
UPDATE 语句中直接设置 updated_at 字段
最直接的方式是在 UPDATE 语句里显式赋值时间戳字段，避免依赖触发器或应用层逻辑。数据库原生时间函数能保证一致性，也绕过时区/精度不一致问题。
常见错误是写成 updated_at = NOW() 却忘了加括号（如误写为 NOW），导致语法错误或字段被设为 0 值；另一类是用字符串拼接时间（如 '2024-01-01 12:00:00'），失去实时性。
- MySQL 推荐用
updated_at = NOW()或更精确的updated_at = CURRENT_TIMESTAMP() - PostgreSQL 用
updated_at = NOW()或updated_at = CURRENT_TIMESTAMP（两者等价） - SQLite 用
updated_at = datetime('now')，注意单引号不能省 - 若字段类型是
TIMESTAMP WITH TIME ZONE（如 PostgreSQL），NOW()自动带时区；若用CLOCK_TIMESTAMP()，则每次调用都重新取系统时间（适合长事务内多次更新）
用 ON UPDATE CURRENT_TIMESTAMP 自动维护（MySQL 专属）
这是 MySQL 特有的表定义级方案，对 updated_at 字段加自动更新约束，后续所有 UPDATE 都无需手动写时间赋值——但有严格前提。
容易踩的坑：该属性只在字段为 TIMESTAMP 或 DATETIME 类型、且未在 UPDATE 语句中显式出现时才生效；一旦你在 SET 子句里写了 updated_at = ...，哪怕值是 NOW()，也会覆盖自动行为。
- 建表时必须指定：
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 如果已有表，需用
ALTER TABLE ... MODIFY COLUMN ... ON UPDATE CURRENT_TIMESTAMP添加（MySQL 5.6.5+） - 不支持多列同时用
ON UPDATE；也不适用于INSERT ... ON DUPLICATE KEY UPDATE场景（此时仍需手动赋值）
PostgreSQL 中用触发器兜底（当不能改表结构时）
PostgreSQL 没有 MySQL 那样的自动更新语法，但可通过触发器实现同等效果。适用场景是：表已上线、字段类型不可改、又无法修改所有业务 SQL 的情况。
关键点在于触发器函数必须返回 NEW，否则更新会被静默丢弃；另外要避免在触发器里调用耗时操作（比如查其他表），否则拖慢所有 UPDATE。
- 先创建函数：
CREATE OR REPLACE FUNCTION update_updated_at_column() RETURNS TRIGGER AS $$ BEGIN NEW.updated_at = NOW(); RETURN NEW; END; $$ language 'plpgsql';
- 再绑定触发器：
CREATE TRIGGER update_updated_at BEFORE UPDATE ON your_table FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); - 若只需对部分字段变更时才更新时间戳，可在函数内加判断，例如
IF NEW.name != OLD.name THEN NEW.updated_at = NOW(); END IF;
应用层写法需统一处理，别让 ORM 漏掉
用 Django、Rails 或 SQLAlchemy 等框架时，常默认忽略时间戳字段，或仅在 save() 时更新，但批量更新（如 QuerySet.update()、session.query().update()）会跳过模型逻辑，导致 updated_at 停滞。
这不是数据库问题，而是 ORM 抽象层的天然盲区——它生成的 SQL 里根本没提 updated_at 字段。
- Django：批量更新必须显式写
.update(updated_at=timezone.now(), ...)，不能依赖auto_now=True - SQLAlchemy：用
update().values(updated_at=func.now())，别用model.updated_at = func.now()后commit()（这不会生效） - 纯 SQL 批量更新（如
UPDATE orders SET status='shipped' WHERE id IN (...)）务必补上updated_at = NOW()，否则这批记录的时间戳就永远卡在最初创建时刻
真正麻烦的不是怎么写这一行 SQL，而是得确认所有路径——包括管理后台的直连更新、定时任务的批量脚本、甚至 DBA 手工执行的修复语句——都没漏掉这个字段。漏一次，数据可信度就打个问号。
