不会出错，但会导致语义偏差：NOW()和CURRENT_TIMESTAMP返回服务器本地时区时间，若业务需存UTC时间，应改用UTC_TIMESTAMP()。
UPDATE 时直接用 NOW() 或 CURRENT_TIMESTAMP 会出错吗？
会，但不是语法错误，而是语义偏差：在 MySQL 中，NOW() 和 CURRENT_TIMESTAMP 默认返回的是服务器本地时区的时间，不是 UTC。如果你的表字段是 DATETIME 类型（无时区），且业务逻辑要求统一存 UTC 时间，直接写 SET updated_at = NOW() 就会导致所有记录被设成本地时间，后续跨时区解析或与 API 对齐时会出现 1–2 小时偏移。
正确做法是显式调用 UTC 函数：
-
UTC_TIMESTAMP()—— 推荐，返回当前 UTC 时间的DATETIME值（如'2024-06-15 12:34:56'），可直接赋给DATETIME字段 -
UTC_DATE()+UTC_TIME()拼接 —— 不必要，且易出错，跳过 -
CONVERT_TZ(NOW(), @@session.time_zone, '+00:00')—— 可行但绕路，性能略差，不推荐
PostgreSQL 怎么批量更新为 UTC 时间？
PostgreSQL 没有 UTC_TIMESTAMP()，但行为更清晰：NOW() 返回 TIMESTAMP WITH TIME ZONE（带时区），而 CURRENT_TIMESTAMP 等价于它。要存纯 UTC 的 TIMESTAMP WITHOUT TIME ZONE，得显式截断时区信息：
- 如果字段是
TIMESTAMP WITHOUT TIME ZONE：用(NOW() AT TIME ZONE 'UTC')，它会把带时区时间转成 UTC 时刻再丢掉时区标识 - 如果字段是
TIMESTAMP WITH TIME ZONE：直接NOW()即可，PostgreSQL 内部已标准化为 UTC 存储，只是显示受客户端timezone设置影响 - 别用
TIMEOFDAY()或CLOCK_TIMESTAMP()—— 前者返回字符串，后者精度高但无必要
示例（PostgreSQL）：
UPDATE users SET updated_at = (NOW() AT TIME ZONE 'UTC') WHERE id IN (1, 2, 3);
WHERE 条件里用 UTC_TIMESTAMP() 会不会导致索引失效？
不会，只要表达式不作用在字段上。比如 WHERE updated_at 是安全的，因为函数作用在常量侧；但 WHERE DATE(updated_at) = DATE(UTC_TIMESTAMP()) 就会让 updated_at 索引失效——DATE() 是对字段的计算。
批量更新时常见陷阱：
- 误写成
WHERE updated_at = NOW()—— 本意是“找旧数据”，结果可能一条都匹配不到（因NOW()是本地时间，而字段存的是 UTC） - 用
BETWEEN包含边界时没考虑秒级精度，导致漏更新最近 1 秒的数据 - 大表更新不加 LIMIT / 分批次 —— 容易锁表或触发 long transaction 报警
SQL Server 和 SQLite 怎么处理？
SQL Server 用 GETUTCDATE()，这是唯一推荐方式。GETDATE() 是本地时间，SYSDATETIMEOFFSET() 带时区，都不适合直接塞进 DATETIME2 字段。
SQLite 没内置 UTC 函数，必须靠 datetime('now', 'utc') —— 注意单引号和字符串字面量写法，写成 datetime(now, 'utc') 会报错 no such function: now。
跨数据库兼容提示：
- 不要依赖
CURRENT_TIMESTAMP的时区行为，它在各库中定义不一致 - 如果项目需多数据库支持，建议封装为应用层生成 UTC 时间字符串（如 Python 的
datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S')），再作为参数传入 SQL —— 更可控，也避开了函数差异
真正容易被忽略的点是：有些 ORM（比如 Django 的 bulk_update）默认不触发表级触发器，而你可能依赖触发器自动填 updated_at；这时手动 UPDATE 反而绕过了逻辑。确认是否真需要 SQL 层批量更新，还是该走应用逻辑补全。
