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=truePHP PDO 设置
PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'"写入时间优先用
datetime类型 + 应用层生成带时区的时间戳，而非依赖
NOW()
时区问题本质是“数据解释一致性”问题，MySQL 设对只是第一步，前后端、存储、传输各环节保持统一才能真正避免错乱。
