SQL时间同步问题本质是时区错位与函数语义混淆；需对齐系统、数据库全局、会话三级时区设置；NOW()受会话时区影响，SYSDATE()返回实时系统时间，UTC函数才真正跨时区一致。
SQL数据库的时间同步问题，核心不在“时间本身”，而在于时区理解错位和时间函数语义混淆。同一句 NOW() 在不同配置下可能返回服务器本地时间、UTC 时间，甚至客户端时区时间——不是数据库“不准”，而是你没告诉它你真正想要什么。
时区设置：三处关键位置必须对齐
数据库时间行为由三个层级共同决定，缺一不可：
-
操作系统时区：MySQL 启动时读取系统
/etc/timezone或timedatectl设置；PostgreSQL 依赖TZ环境变量。若系统设为Asia/Shanghai，但数据库未显式覆盖，就默认按此解析字符串和显示结果。 -
数据库全局时区（system_time_zone / timezone）：MySQL 的
system_time_zone是只读的（继承系统），但time_zone可动态设为'+08:00'或'Asia/Shanghai'；PostgreSQL 的timezone参数可设为'PRC'或'UTC'，影响所有会话默认行为。 -
会话级时区（per-connection）：连接建立后可用
SET time_zone = '+00:00';（MySQL）或SET TIME ZONE 'UTC';（PG）临时覆盖。Web 应用常在此层统一设为 UTC，避免业务逻辑受部署地干扰。
NOW()、CURDATE()、SYSDATE() 不是同一件事
这些函数表面相似，底层机制和时区敏感性差异极大：
-
NOW()和CURDATE()返回语句开始执行时的当前时间，受会话时区影响，且在整个语句中保持不变（比如在 INSERT 多行时值相同）。 -
SYSDATE()（MySQL 特有）返回函数实际执行时刻的系统时间，不受语句起始时间约束，也不受会话时区“转换”——它先取系统时间，再按当前time_zone值做格式化输出，容易造成“看起来跳变”的错觉。 -
UTC_TIMESTAMP()和CURRENT_TIMESTAMP AT TIME ZONE 'UTC'（PG）才真正返回协调世界时，不依赖本地设置，适合跨时区日志、定时任务触发判断。
存储时间类型选错，等于埋雷
DATETIME 和 TIMESTAMP 表面都是存时间，行为却相反：
-
DATETIME（MySQL）/TIMESTAMP WITHOUT TIME ZONE（PG）：纯数值存储，不记录时区信息。插入'2024-05-10 14:30:00'就原样存，读出来也原样返——它不自动转换，也不代表任何时区。适合存“固定时刻”如会议开始时间（明确属于东八区）。 -
TIMESTAMP（MySQL，默认带时区语义）/TIMESTAMP WITH TIME ZONE（PG）：内部统一转为 UTC 存储，读取时按当前会话时区自动转换。插入'2024-05-10 14:30:00'在东八区会话中，存的是2024-05-10 06:30:00 UTC；换到 UTC 会话里读，就显示2024-05-10 06:30:00。适合存“事件发生时间”（如用户登录），需全局可比。
应用层最稳妥的做法：统一用 UTC 存储 + 显式转换展示
不依赖数据库自动时区推断，把控制权拿回来：
- 数据库字段统一用
TIMESTAMP WITH TIME ZONE（PG）或TIMESTAMP（MySQL），初始化连接时强制SET time_zone = '+00:00'; - 所有写入都用 UTC 时间字面量，例如
INSERT INTO log (ts) VALUES (TIMESTAMP '2024-05-10 06:30:00+00');或调用UTC_TIMESTAMP() - 查询展示时，由应用或 SQL 显式转换：
SELECT ts AT TIME ZONE 'Asia/Shanghai' AS local_time FROM log;（PG）或CONVERT_TZ(ts, '+00:00', '+08:00')（MySQL）
时区不是玄学，时间函数也不是黑盒。看清每一步的输入来源、转换环节和输出语义，比盲目加 SET time_zone 更有效。不复杂但容易忽略。
