curdate()和curtime()返回服务器本地时区时间，非utc且不受客户端影响；应使用utc_date()、utc_time()、utc_timestamp()获取utc时间，确保跨时区一致性。
CURDATE() 和 CURTIME() 返回的是服务器本地时区时间
这两个函数不返回 UTC，也不受客户端时区影响，只看 mysql 服务进程启动时读取的系统时区（system_time_zone）或配置的 time_zone 变量。如果你在 docker 容器里没显式设置时区，大概率是 UTC，但宿主机上可能是 CST 或其他——结果完全不可控。
常见错误现象：select CURDATE(), NOW() 在开发机和生产库返回不同日期，导致定时任务漏跑或重复；用 CURDATE() 做分区表切换条件，凌晨 0 点切错分区。
- 查当前会话时区：
SELECT @@session.time_zone - 查全局默认时区：
SELECT @@global.time_zone - 临时改会话时区（仅当前连接有效）：
SET time_zone = '+00:00' - 永久生效需在
my.cnf加default-time-zone='+00:00'，然后重启 mysqld
想拿 UTC 时间，别用 CURDATE()/CURTIME()，改用 UTC_* 函数
CURDATE() 和 CURTIME() 没有 UTC 版本，强行转换容易出错。MySQL 提供了原生 UTC 函数，语义清晰、无歧义。
使用场景：日志时间戳统一存 UTC、跨时区报表按 UTC 日切分、与 Java/Python 的 datetime.utcnow() 对齐。
-
UTC_DATE()→ 返回DATE类型的 UTC 当前日期（如'2024-06-15'） -
UTC_TIME()→ 返回TIME类型的 UTC 当前时间（如'14:22:03'） -
UTC_TIMESTAMP()→ 返回DATETIME类型的 UTC 当前时间戳（推荐，精度高、类型通用） - 注意：
UTC_TIMESTAMP()不接受参数，UTC_TIMESTAMP(3)是非法写法
NOW() vs UTC_TIMESTAMP()：时区陷阱最常踩的坑
NOW() 是 SYSDATE() 的同义词，它返回的是函数执行时刻的系统时间——不是语句开始时间，且依赖会话时区。而 UTC_TIMESTAMP() 总是返回 UTC，且在同一个语句内多次调用值一致（确定性函数），适合做一致性快照。
性能影响：两者底层开销几乎一样，但 NOW() 在复制环境中可能因主从时区不一致导致 binlog 重放偏差；UTC_TIMESTAMP() 则天然规避该问题。
- 错误写法：
INSERT INTO log (ts) VALUES (CURDATE())→ ts 字段是 DATETIME 类型，隐式转成'2024-06-15 00:00:00'，丢失时间部分 - 正确写法：
INSERT INTO log (ts) VALUES (UTC_TIMESTAMP())→ 明确、完整、可预期 - 兼容性提醒：MySQL 5.6+ 支持
UTC_TIMESTAMP()；mariadb 同样支持，但旧版 Percona 可能有微小行为差异
应用层传时间 vs 数据库生成时间：UTC 统一必须端到端对齐
哪怕数据库用了 UTC_TIMESTAMP()，如果应用层（比如 Python 的 datetime.now()）直接传本地时间进 DB，整个链路就破了。UTC 不是“选配”，是必须贯穿的契约。
容易被忽略的地方：ORM 默认行为。django 的 auto_now_add=True 用的是数据库 NOW()，不是 UTC；SQLAlchemy 的 func.now() 同理。不显式干预，就会埋雷。
- Python 中安全做法：
datetime.utcnow()或datetime.now(timezone.utc)（推荐后者，明确带时区） - Django 配置：
USE_TZ = True+TIME_ZONE = 'UTC'，再配合auto_now_add=True才真正可靠 - Java JDBC 连接串加
serverTimezone=UTC，否则PreparedStatement.setTimestamp()可能悄悄转成本地时区