17370845950

MySQL默认时区为SYSTEM，需通过确认当前时区、统一设置服务端时区（修改my.cnf并重启）、必要时调整客户端行为来解决；应用层应显式指定时区以确保一致性。

MySQL 默认时区通常是 SYSTEM（即继承操作系统的时区），但很多情况下，系统时区没配好、容器环境未同步、或应用需要统一使用 UTC/东八区，就会导致时间字段写入、查询、函数（如 NOW()、CURDATE()）结果与预期不符。解决核心是：**确认当前时区 → 统一设置 MySQL 服务端时区 → 必要时调整客户端行为**。

查清当前 MySQL 实际使用的时区

登录 MySQL 后执行：

SELECT @@global.time_zone, @@session.time_zone;

常见返回组合：

• SYSTEM + SYSTEM → 完全依赖系统时区
• +00:00 + +00:00 → 强制 UTC
• Asia/Shanghai + SYSTEM → 全局设了标准时区名，会话继承

再查系统时区是否正确（Linux）：

timedatectl | grep "Time zone"

若显示 UTC 或其他非 Asia/Shanghai，说明底层就不对，需先修正系统时区。

永久修改 MySQL 服务端时区（推荐）

编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/my.cnf），在 [mysqld] 段下添加：

[mysqld]
default-time-zone = '+08:00'

或使用命名时区（需系统支持该时区名）：

default-time-zone = 'Asia/Shanghai'

保存后重启 MySQL：

sudo systemctl restart mysql

⚠️ 注意：修改后必须重启 mysqld 进程才生效；仅执行 SET GLOBAL 是临时的，重启即丢失。

不重启情况下的临时调整（调试用）

适用于无法重启或快速验证：

• 修改当前会话时区：SET time_zone = '+08:00';
• 修改全局时区（影响新连接）：SET GLOBAL time_zone = '+08:00';
• 查看当前会话时间：SELECT NOW(), SYSDATE(), UTC_TIMESTAMP(); 对比差异

注意：SET GLOBAL 要求有 SUPER 权限，且只对之后新建的连接生效，已存在的连接不受影响。

应用层配合建议（避免隐式转换）

即使 MySQL 设为 +08:00，某些 ORM 或 JDBC 驱动仍可能按 UTC 解析时间字段。建议：

• JDBC 连接串显式指定时区：?serverTimezone=Asia/Shanghai&useTimezone=true
• PHP PDO 设置 PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'"
• 写入时间优先用 datetime 类型 + 应用层生成带时区的时间戳，而非依赖 NOW()

时区问题本质是“数据解释一致性”问题，MySQL 设对只是第一步，前后端、存储、传输各环节保持统一才能真正避免错乱。