MySQL时间不一致主因是服务器系统、MySQL服务、客户端连接三层时区未统一；需分别检查timedatectl、@@global.time_zone、NOW()等，配置default-time-zone='+08:00'并重启，客户端连接指定serverTimezone=Asia/Shanghai，新建表优先用DATETIME。
MySQL 时间不一致，绝大多数情况是时区配置没对齐——服务器系统时区、MySQL 服务时区、客户端连接时区三者不统一导致的。重点不是改一个地方，而是让它们协同一致。
确认当前各层时区设置
先查清楚问题在哪一层：
- 系统时区：
timedatectl status（Linux）或date命令看系统时间与本地是否一致 - MySQL 服务时区：
SELECT @@global.time_zone, @@session.time_zone; - 连接时区：
SELECT NOW(), SYSDATE(), UTC_TIMESTAMP();对比结果差异
统一 MySQL 服务默认时区
推荐在 MySQL 配置文件（my.cnf 或 my.ini）的 [mysqld] 段落中显式指定：
注意：不要用 SYSTEM，它依赖系统时区且易被忽略变更
- 设为东八区（中国标准时间）：
default-time-zone = '+08:00' - 重启 MySQL：
systemctl restart mysqld（或对应服务名） - 验证：
SELECT @@global.time_zone;应返回+08:00
确保应用连接使用正确时区
即使服务端设对了，客户端连接仍可能覆盖时区：
- JDBC 连接串加参数：
?serverTimezone=Asia/Shanghai（推荐用命名时区，兼容夏令时） - PHP PDO 可在 DSN 中加
;timezone=Asia/Shanghai，或执行SET time_zone = '+08:00'; - 命令行客户端启动时加
--default-authentication-plugin=mysql_native_password --defaults-extra-file或连接后手动执行SET time_zone = '+08:00';
避免 TIMESTAMP 和 DATETIME 的隐式陷阱
两者行为不同，容易混淆：
-
TIMESTAMP存储时会转成 UTC，读取时再按当前会话时区转回——所以必须保证会话时区准确 -
DATETIME不做任何转换，存啥读啥——适合记录“固定时间点”（如发布会开始时间），但需业务层自行保障写入值的时区含义 - 新建表建议优先用
DATETIME，除非明确需要跨时区自动转换
