mysql本身不管理时钟同步，只信任系统时间；需确保ntp服务启用且偏移≤±50ms、my.cnf中配置default-time-zone='+08:00'并重启mysqld、timestamp字段会自动时区转换而datetime不会、客户端连接必须显式指定servertimezone参数。
systemd-timesyncd 或 chronyd 必须启用且稳定
MySQL 的 NOW()、CURRENT_TIMESTAMP 全部来自系统时钟。如果系统时间漂移，MySQL 就跟着漂移，这不是 bug，是设计使然。
- 运行
timedatectl status，确认输出中包含System clock synchronized: yes和service: chronyd（或systemd-timesyncd） - 检查偏移量：
chronyc tracking | grep "Offset"或timedatectl timesync-status | grep "offset"，理想值在 ±50ms 内 - 若未启用，执行：
sudo systemctl enable --now chronyd（CentOS/RHEL）或sudo systemctl enable --now systemd-timesyncd（Debian/Ubuntu） - 容器环境需额外注意：基础镜像常默认关闭 NTP，必须在启动时挂载 host 的
/etc/chrony.conf或注入chronyd进程
my.cnf 中必须写 default-time-zone，不是 time_zone
time_zone 是 SQL 层变量名，不能写进配置文件；写进去会导致 MySQL 启动失败或静默忽略。唯一合法的全局配置项是 default-time-zone。
- 推荐写法：
default-time-zone = '+08:00'—— 固定偏移，不依赖系统时区表，无兼容性风险 - 避免写
default-time-zone = 'Asia/Shanghai'：除非你已手动执行过mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql并验证SELECT COUNT(*) FROM mysql.time_zone_name;> 0 - 配置位置必须在
[mysqld]段下，保存后必须systemctl restart mysqld；热重载（如mysqladmin reload）完全不生效 - 验证是否生效：
SELECT @@global.time_zone, @@session.time_zone;应返回+08:00，而非SYSTEM
TIMESTAMP 字段会偷偷转 UTC，DATETIME 不会
这是最容易被忽略的底层行为差异，直接导致“存进去就变时间”。
-
TIMESTAMP存的是 UTC 时间：插入'2024-01-01 12:00:00'到 +08:00 时区的TIMESTAMP字段，实际存入的是2024-01-01 04:00:00（UTC） -
DATETIME原样存储、原样返回，完全不转换；适合记录“固定时刻”（如发布会开始时间） - 主从复制中若用
TIMESTAMP+ STATEMENT 格式 binlog，主库NOW()写入的时间字面量，会被从库按自身time_zone解析，结果错位 - 新表设计优先用
DATETIME；已有TIMESTAMP字段，务必保证应用层、连接池、MySQL 全局/会话时区三者严格一致
JDBC 等客户端连接必须显式指定 serverTimezone
即使服务端配对了，客户端驱动仍可能因未明确时区而 fallback 到 SYSTEM，触发 Server returns invalid timezone 错误。
- JDBC URL 必须带参数：
?serverTimezone=Asia/Shanghai（推荐）或?serverTimezone=GMT%2B8 - 仅加
useTimezone=true不够，它只是开启转换逻辑，没指定具体时区照样报错 - 若用
serverTimezone=Asia/Shanghai，需确保 MySQL 已加载时区表（否则驱动无法解析，仍失败） - Python pymysql、Node.js mysql2 等也需在连接选项中设置对应时区参数，不能依赖服务端默认
default-time-zone 且重启了没、客户端连接串里有没有 serverTimezone——漏掉任意一层，NOW() 就可能“慢 8 小时”。
