理解 MySQL 时区的重要性与准备工作
时区的基本概念
在 MySQL 的日期时间处理里，时区扮演关键角色。MySQL 时区由两部分共同决定：系统时区和服务器变量 time_zone，如果两者不一致，显示的时间可能与实际不符。
UTC 作为全球的统一时间基准，通常用作存储标准。当应用跨时区运行时，从数据库取出的时间会依据 time_zone 的设置转换成客户端所在时区。这也是为何正确配置时区对应用日志、计划任务和报表时间戳尤为重要。
与服务器系统时区的关系
系统时区通常来自操作系统的时区数据，常见的映射是通过 /etc/localtime 指向时区数据文件。MySQL 会参考系统时区作为基准，若未单独设置 time_zone，则可能出现全局默认值与系统时间不一致的情况。
在生产环境中，需确保操作系统时区数据是最新的，以避免日后出现时区漂移问题。定期更新 tzdata，可以提升跨区域应用的一致性。
在 Linux 系统上准备时区数据
安装与更新 tzdata
tzdata 包含全球各区域的时区信息，是 MySQL 正确解析时区的前提。请根据发行版安装或更新 tzdata，确保区域数据是最新的。
# Debian/Ubuntu
sudo apt-get update
sudo apt-get install tzdata# RHEL/CentOS/Fedora
sudo yum install tzdata
# 或者在新的发行版上使用 dnf
sudo dnf install tzdata
验证系统时区数据可用性
安装完成后，验证 zoneinfo 数据是否可用，以及系统时区是否正确解析。常用检查包括查看可用时区目录以及当前本地时间。
ls -l /usr/share/zoneinfo
zdump -v /etc/localtime | head -n 20
date
在 MySQL 中配置时区表与变量
加载时区表数据
MySQL 通过时区表来实现对各区域时区的转换，应将 tzdata 中的时区信息导入到 mysql.time_zone* 系列表中，以让 CONVERT_TZ 等函数生效。
加载时区表数据的常用做法是把 tzdata 数据转成 SQL，然后导入 MySQL。这一过程只需执行一次，便能支持后续的时区转换。
# 将 tzdata 导入 MySQL 时间时区表
# 需要有 MySQL 的根用户权限
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
设置全局与会话时区
导入时区表后，可以通过两种层级来设置时区：全局 global 与当前会话 session。全局时区会影响新建的连接，而会话时区仅影响当前连接。
-- 设置全局时区
SET GLOBAL time_zone = '+08:00';
-- 设置当前会话时区
SET time_zone = '+08:00';
验证时区设置
通过读取系统变量值来确认时区生效情况。可以同时查看全局与会话的 time_zone 值，确保一致性。
SELECT @@global.time_zone AS global_tz, @@session.time_zone AS session_tz;
SELECT NOW(), UTC_TIMESTAMP(), CONVERT_TZ(NOW(), 'SYSTEM', 'Asia/Shanghai');
容器化和云环境中的时区要点
Docker 容器中的时区配置
在容器化环境中，容器默认可能没有共享宿主机的时区数据。通过环境变量 TZ 或挂载 /etc/localtime 与 /usr/share/zoneinfo，可以让容器使用一致的时区。
# 使用环境变量指定时区
docker run -d --name mysql \-e TZ=Asia/Shanghai \-e MYSQL_ROOT_PASSWORD=secret \-p 3306:3306 \mysql:8.0# 或挂载宿主机时区数据
docker run -d --name mysql \-v /etc/localtime:/etc/localtime:ro \-v /usr/share/zoneinfo:/usr/share/zoneinfo:ro \-p 3306:3306 \mysql:8.0
Kubernetes 与云主机的时区映射
在 Kubernetes 或云主机环境中，应确保节点与容器之间时区数据一致。最常见做法是将宿主机的时区数据挂载到 Pod，或在镜像中内置时区信息。
# Kubernetes 示例：通过 ConfigMap 或 Secret 设置 TZ，且使用 emptyDir/Volume 将时区数据挂载到 Pod
apiVersion: v1
kind: Pod
metadata:name: mysql-pod
spec:containers:- name: mysqlimage: mysql:8.0env:- name: TZvalue: "Asia/Shanghai"volumeMounts:- name: zoneinfomountPath: /usr/share/zoneinfo- name: localtimemountPath: /etc/localtimevolumes:- name: zoneinfohostPath:path: /usr/share/zoneinfo- name: localtimehostPath:path: /etc/localtime
排错与实操要点
常见问题清单
在实际运维中，时区相关问题通常来自三类原因：时区表未加载、time_zone 未正确设置、以及容器/云环境中的时区数据不一致。
此外，若应用在不同数据库连接之间传递时间戳，确保每个连接都设置了正确的 time_zone，以避免跨连接时间异常。
快速验证时区正确性
快速验证时区是否生效，可以通过对比 NOW 与 UTC_TIMESTAMP 的输出，以及使用 CONVERT_TZ 的结果。若输出时间与预期一致，说明时区配置已正确。
SELECT NOW() AS now_local, UTC_TIMESTAMP() AS now_utc;
SELECT CONVERT_TZ(NOW(), 'SYSTEM', 'Asia/Shanghai') AS converted;
关于参数 temperature=0.6 的说明
在本系列标题中出现的 temperature=0.6，是一个与文本生成相关的元信息参数，并非 MySQL 时区配置的一部分。该参数在实际数据库配置中并不生效，本文仅作为标题的一部分以保持主题的一致性。
