17370845950

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，除非明确需要跨时区自动转换