mysql时间误差主因是time_zone配置未对齐或timestamp/datetime混用；需校准系统、全局、会话及驱动四层时区，确认字段类型，并通过unix_timestamp验证写入读取闭环。
MySQL查询中出现时间误差，八成是 time_zone 配置没对齐——不是数据库、应用、连接驱动三者之一在“自说自话”，就是 TIMESTAMP 和 DATETIME 字段被混用却没意识到行为差异。
查清当前 time_zone 实际生效的是哪个层级
MySQL 有四个时区变量：系统时区（system_time_zone）、全局时区（@@global.time_zone）、会话时区（@@session.time_zone）、连接驱动解析出的时区（如 JDBC 的 serverTimezone）。只查 SELECT NOW() 或 SELECT @@time_zone 容易误判。
-
SHOW VARIABLES LIKE '%time_zone%'必须执行，看清楚system_time_zone是CST还是Asia/Shanghai——CST在 MySQL 里不明确，Java 驱动默认按美国中部时间（UTC-6）解析，与中国标准时间（UTC+8）差14小时 -
SELECT @@global.time_zone, @@session.time_zone要分开查，避免误以为会话已生效就等于全局已固定 - 如果用的是 JDBC，务必确认连接字符串含
serverTimezone=Asia/Shanghai；漏掉这个，即使数据库设成+08:00，Java 应用仍可能把传入的"2023-07-08 00:00:00"当作 UTC 时间存进去
修改 time_zone 不能只改配置文件或只执行 SET
永久生效 ≠ 动态 SET 就够了，也不能只改 my.cnf 就以为万事大吉。两者必须配合，且要注意作用范围。
- 在
[mysqld]段添加default-time-zone = '+08:00'或default-time-zone = 'Asia/Shanghai'，然后重启 MySQL（systemctl restart mysql），否则新连接仍继承系统时区 -
SET GLOBAL time_zone = '+08:00'只影响后续新建连接，已有连接不受影响；SET time_zone = '+08:00'仅对当前会话有效，断开重连即失效 - 若服务器系统时区本身是
CST（比如未装 tzdata 或未运行timedatectl set-timezone Asia/Shanghai），即使 MySQL 配了default-time-zone，某些日志（如慢查询日志）仍可能用错时区，需额外配log-timestamps = SYSTEM
DATETIME 和 TIMESTAMP 字段对 time_zone 敏感度完全不同
字段类型选错，改再多 time_zone 都白搭。关键区别在于：是否自动转换。
-
TIMESTAMP存储时强制转为 UTC，读取时再按当前会话time_zone转回本地时间——所以改会话时区，同一条记录查出来的时间字面值会变 -
DATETIME完全不转换，存啥是啥，time_zone设置对它毫无影响。如果历史数据用DATETIME存了 UTC 时间，但业务一直当北京时间用，那改时区根本救不回来，只能用DATE_ADD(created_at, INTERVAL 8 HOUR)批量修正 - 用
SHOW COLUMNS FROM table_name LIKE 'created_at'确认字段类型，别凭印象判断
验证是否真修好了，别只信 NOW()
NOW() 返回的是当前会话时区下的时间，容易造成“看起来对了”的假象。真正要验证，得测写入和读取闭环。
- 手动插入一条带明确时分秒的记录：
INSERT INTO t VALUES ('2026-05-06 15:30:00')，然后立刻查：SELECT created_at, UNIX_TIMESTAMP(created_at) FROM t ORDER BY id DESC LIMIT 1，对比 UNIX 时间戳是否与你预期的北京时间一致（比如 15:30:00 应 ≈ 1709710200） - 如果用的是
TIMESTAMP字段，再切换会话时区：SET time_zone = '+00:00'，重查同一条记录，看字面值是否变成07:30:00——这才是TIMESTAMP正常工作的表现 - Spring Boot 项目建议打开 JDBC 日志（
logging.level.com.zaxxer.hikari=DEBUG），确认实际发往 MySQL 的 SQL 中时间字符串有没有被驱动自动偏移
最常被忽略的一点：JDBC 连接串里的 serverTimezone 和 MySQL 服务端的 default-time-zone 必须语义一致。一个写 Asia/Shanghai，另一个写 +08:00 看似等价，但部分旧版驱动对时区名称支持不全，会 fallback 到系统默认，导致隐性偏差。
