你有没有过这种经历：某天凌晨被值班电话叫醒，说订单报表时间对不上，查了半天发现数据库时间和业务实际时间差着8个小时。我遇到过不止一次，而且每次表现还不一样——有时是全部时间都偏，有时是只有TIMESTAMP字段在偏，DATETIME却好好的。排查MySQL时区问题，绕不开三个东西：操作系统时区、set global time_zone动态修改，以及配置文件里的default-time-zone参数。这篇文章把我这些年攒下的时区修改经验和踩坑记录整理成一套可以直接参考的做法，适合正在被时间对不上问题折磨的后端开发、运维和DBA，也适合想从原理层面搞懂时区机制的人。
1. 为什么数据库时间和本地时间对不上：先定位时区在MySQL里的真实形态
1.1 一个典型的“只差8小时”案例
某一次，模拟项目X的支付对账单总是比实际时间早8小时。业务方一口咬定是数据库的问题。我到现场先跑了一句SELECT NOW()，返回的是正确时间，再跑业务SQL，时间又是错的。当时第一反应是连接层，于是开了一个新连接，直接查SELECT @@session.time_zone，返回SYSTEM，再查系统的date，发现操作系统是UTC时间。问题基本定位：MySQL的global时区没有显式设置，全部走SYSTEM，而SYSTEM是UTC。
这类问题在“模板镜像服务器”上特别常见。很多团队用云厂商或机房里通用镜像装机，镜像里的系统时区未必和业务时区一致。数据库装好后没有显式配置时区，于是继承了一个UTC环境。应用层写时间的时候，如果代码里是用本地时区生成字符串，表面上是正常的；一旦某天有人改成用数据库函数NOW()、CURRENT_TIMESTAMP或者触发器来写时间，就突然出现8小时偏移。所以排查时区问题不要一上来就看代码，先把整条链路的时间基准搞清楚。
1.2 DATETIME和TIMESTAMP：差8小时为什么只发生在部分字段上
很多人在排查时发现：同一张表里，create_time错8小时，pay_time却完全正常。这种差异往往不是时区没改，而是这两个字段的类型不同。MySQL里时间类型最重要、也最容易被忽略的区别，就是DATETIME和TIMESTAMP的存储机制。
DATETIME存的是字面值。你写入2024-11-20 10:00:00，查询出来就是2024-11-20 10:00:00，跟会话时区没有任何关系。TIMESTAMP则完全不同，它内部统一按UTC存储。写入时，MySQL会先把你的值按“当前会话时区”换算成UTC，查询时再按“当前会话时区”换算回来。
举个例子：假设会话时区是+08:00，你往TIMESTAMP字段写入2024-11-20 10:00:00，底层实际上存的是2024-11-20 02:00:00这个UTC时刻。之后如果换一个+00:00的会话去查，结果会显示成2024-11-20 02:00:00。数据本身没有变，变的是展示视角。用一个生活化类比：DATETIME像商品包装上印好的生产日期，印几点就是几点；TIMESTAMP像称重电子秤上的克数，你可以换算成公斤、斤、盎司，底层的物理量不变，但不同地区的人看到的结果不一样。很多人“改了时区后历史数据错乱了”，其实不是数据被改，而是TIMESTAMP列换了换算基准，旧值按新规则展示后看起来全变了。
1.3 三层时区变量：系统、全局、会话的读取顺序
MySQL的时区不是一个单点设置，而是一个三级结构。@@system_time_zone是操作系统时区，一般只读，MySQL启动时如果没拿到显式配置，最终就会落到它上面。@@global.time_zone是库级全局时区，新建立的连接默认继承它。@@session.time_zone是当前会话时区，默认继承全局值，但也可以单独改，只影响当前连接。
可以用下面这条SQL一眼看全三个值：
SELECT @@system_time_zone AS sys_tz, @@global.time_zone AS g_tz, @@session.time_zone AS s_tz;实际查询时，time_zone字段常见的值是SYSTEM、+08:00、UTC。其中SYSTEM有特殊含义：表示“我没有显式指定，去问操作系统要”。所以当global和session都显示SYSTEM时，真正决定时间显示的是操作系统时区。这就是为什么很多人用SET GLOBAL time_zone='+08:00'后立刻查看，当前会话还是SYSTEM——因为老连接压根没刷新。
2. set global time_zone：改了却不生效的三个真实原因
2.1 一条看起来很对的命令，为什么马上验证还是原样
生产环境里救火，我们一般先执行：
SET GLOBAL time_zone = '+08:00';执行完之后，习惯性在当前连接里跑SHOW VARIABLES LIKE 'time_zone';，结果还是SYSTEM。这时候容易得出一个错误结论：命令没生效。实际上命令是生效了的，只是它影响的不是你当前这个会话。MySQL的time_zone是会话级变量，全局值只是“给未来新连接用的默认值”，当前会话以及所有已经建立的连接，它们持有的是各自进入连接时的会话时区，不会因为全局值变化而被回溯修改。
要验证全局值是否生效，必须开一个“新的连接”。新连接里查SELECT @@session.time_zone;，会发现已经变成+08:00。如果你用的是连接池，还要注意：连接池里可能还躺着大量旧连接，这些连接不会立刻刷新。所以修改完全局时区后，应用侧经常要配合一次连接池重建或重启应用，才能确保所有线程拿到新时区。
2.2 重启即丢：set global只改内存，不改配置
第二个容易踩的坑：SET GLOBAL改的只是运行内存中的值。一旦mysqld重启，它又回到启动参数或配置文件里定义的状态。假设配置里没写过时区相关项，重启后global会重新变成SYSTEM，也就回到操作系统时区。这种“救火成功，重启复燃”的情况在运维中太常见了。
动态修改适合临时救急，不适合做长期状态管理。如果想让配置固化，要么改配置文件里的default-time-zone，要么在MySQL 8.0里用SET PERSIST。个人经验：线上环境除非是临时解决线上问题，否则我尽量不单独执行SET GLOBAL，因为很容易忘记同步配置文件，造成“为什么重启后又不对了”的二次事故。
2.3 权限不足：报错ERROR 1227是怎么回事
另一个被忽略的点是权限。普通业务账号执行SET GLOBAL time_zone='+08:00';时，经常会收到ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN privilege(s) for this operation。MySQL 5.7需要SUPER权限，8.0引入了更细粒度的SYSTEM_VARIABLES_ADMIN权限。如果生产账号只授权了业务库的增删改查，修改全局变量自然是失败的。
我的建议是：把时区变更当成一个正式的变更动作来做，不走业务账号。运维或DBA使用带着SYSTEM_VARIABLES_ADMIN或SUPER权限的管理账号执行，并记录操作时间、操作原因、影响范围。如果权限受限又确实需要临时修改，可以和数据库负责人确认授权方案，不要把这类命令塞进业务代码里自动执行。
2.4 set global的正确使用姿势
动态修改真正合适的场景是：线上数据库无法马上重启，但业务时间已经偏移，需要立刻止血。操作顺序一般是：
-- 1. 确认当前值 SELECT @@global.time_zone; -- 2. 修改全局默认值，让之后新建的连接拿到正确时区 SET GLOBAL time_zone = '+08:00'; -- 3. 修改当前会话，保证自己接下来的验证是干净的 SET time_zone = '+08:00'; -- 4. 立即在同一个会话内验证 SELECT NOW(), UTC_TIMESTAMP();止血完成后，别忘了补一道“持久化”工作，否则下次重启问题还会回来。这正是下一节配置文件方案的价值。
3. 配置文件default-time-zone：把时区固化成永久的正确值
3.1 写进哪个配置段，写在哪个文件里
持久化时区修改，标准做法是在MySQL配置文件的[mysqld]段下加一行：
[mysqld] default-time-zone = '+08:00'注意是mysqld段，不是[client]，也不是[mysql]。前者影响服务端，后者只影响命令行客户端。写错段落是新手常用的错误，改完配置文件重启后，查SHOW VARIABLES LIKE 'time_zone';发现还是SYSTEM。
配置文件位置因发行版而异。常见的有/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf等。有些系统里主配置会include额外目录下的文件，比如/etc/mysql/conf.d/。可以用这种方式确认当前读取的配置路径：
mysqld --verbose --help | grep -A 1 "default-time-zone"或者：
my_print_defaults mysqld3.2 三种取值：SYSTEM、固定偏移、命名时区
default-time-zone支持三类值：
| 取值示例 | 含义 | 适用场景 |
|---|---|---|
SYSTEM | 跟随操作系统时区 | 默认值，不推荐用于生产 |
+08:00 | 固定偏移，没有夏令时概念 | 国内业务首选，简单直接 |
Asia/Shanghai | IANA命名时区 | 有时区表支撑，适合需要DST的海外部署 |
命名时区不是装上就能用的。MySQL的mysql.time_zone_name表默认只有SYSTEM和UTC，要支持Asia/Shanghai这类命名时区，必须先加载系统时区表。常见做法是把本机/usr/share/zoneinfo下的时区数据导入MySQL：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql加载完成后，配置才能写成default-time-zone = 'Asia/Shanghai'。如果时区表没加载，启动或修改变量时会报“Unknown or incorrect time zone”错误。
国内业务有个实际情况：东八区全年无夏令时，固定偏移+08:00和命名时区Asia/Shanghai在结果上完全等价。因此我建议能用偏移量就用偏移量，少一份时区表依赖，少一种故障可能。只有业务跨多个有时令规则的国家或地区时，才需要引入命名时区。
3.3 改配置文件的完整操作流程
生产环境里我不建议只改配置文件，因为配置不会立刻加载，必须重启才能生效。更稳妥的流程分四步：
- 先用
SET GLOBAL动态修改，让新连接马上正确，属于“在线止血”。 - 修改配置文件，写入
default-time-zone，让重启后依然正确，属于“固化状态”。 - 选择一个低峰窗口重启mysqld，同时评估重启对现有连接的影响。
- 重启后执行前面那三条SELECT，确认值都没变。
这里有个容易被低估的点：重启MySQL会导致所有连接断开，连接池里的连接会重新建立。如果应用没有合理的重连机制，重启瞬间可能有一波“连接失败”的报错。所以实际操作上，尽量在业务低峰期做，并且先通知应用负责人。
3.4 MySQL 8.0的SET PERSIST：不用手改配置文件的持久化方案
除了手改配置文件，MySQL 8.0还提供了更现代化的持久化方式。SET PERSIST会同时修改运行时值，并把变更写入mysqld-auto.cnf，因此重启后依然生效。比如：
SET PERSIST time_zone = '+08:00';如果只想把参数写入持久化文件，暂时不改变当前全局值，可以用SET PERSIST_ONLY。这个功能的最大好处是避免手改配置文件时出现格式错误、段名错误这类粗心问题。不过mysqld-auto.cnf也是配置文件，发布配置时需要一并纳入版本管理，不然在某一台新机器上初始化MySQL时，状态会和其他机器不一致。
4. 改完怎么验证：不要只会SHOW VARIABLES
4.1 每次修改后都执行同一套验证SQL
很多人在修改时区后只查一句SHOW VARIABLES LIKE 'time_zone';，看到+08:00就觉得没问题了。这远远不够。我更推荐下面的组合验证语句：
SELECT @@system_time_zone AS sys_tz, @@global.time_zone AS g_tz, @@session.time_zone AS s_tz, NOW() AS local_now, UTC_TIMESTAMP() AS utc_now, TIMEDIFF(NOW(), UTC_TIMESTAMP()) AS tz_offset;这里面最关键的是TIMEDIFF(NOW(), UTC_TIMESTAMP())。如果配置正确，它应该返回08:00:00（东八区）。如果返回00:00:00，说明当前会话时区实际是UTC。如果返回一个奇怪的小时数，说明时区配置或系统时区有问题。这一条SQL能直接验证“当前连接真正使用的时区”，而不是只看变量定义。
4.2 观察到的值与问题层级的对应关系
| 现象 | 可能的根因 |
|---|---|
sys_tz、g_tz、s_tz全是SYSTEM | 操作系统时区不对，先改系统时区 |
g_tz和s_tz不一致 | 连接池或应用显式修改过会话时区 |
g_tz和s_tz都是+08:00，但应用查询仍偏移 | 连接串里的时区参数有问题 |
重启后g_tz和s_tz回到SYSTEM | 配置未持久化，缺default-time-zone设置 |
用这张表去对照，基本能缩小排查范围。值得强调的是“应用查询仍偏移”这一类，因为服务端已经全对，但应用侧的时间转换参数还会引入额外偏移，这是下一章重点讲的内容。
4.3 改完时区后，历史TIMESTAMP数据会不会损坏
这是一个经常引起恐慌的疑问。修改时区后，用SQL查历史TIMESTAMP字段，发现所有时间都变了8小时，有人会以为数据被“改写”了。其实不是。TIMESTAMP底层存的是UTC时刻，这个UTC时刻没有变，变的是会话时区这个“展示规则”。查出不同的字符串，本质上和“同一个时刻在北京叫20点，在伦敦叫12点”一样，不代表数据损坏。
DATETIME字段更简单，它存的就是字面量，查询结果完全不受时区影响。所以只要搞清楚字段类型，就不会被“时间错乱”的假象吓到。
5. serverTimezone与连接串：应用侧最容易漏掉的一环
5.1 服务端全对，应用读出来还是错的
有一段时间我连续接到几个类似问题：数据库服务器@@global.time_zone和@@session.time_zone都已经显示+08:00，直接跑MySQL命令行也正确，但Java应用查出来的java.sql.Timestamp打印出来却差了8小时。最后定位到的问题是JDBC连接串。
MySQL的驱动在建立连接时，会和服务端协商时区。以Connector/J为例，如果连接串里没有显式指定serverTimezone，驱动通常会拿客户端JVM的默认时区去推测。应用服务器如果部署在UTC时区的容器里，驱动就会按UTC解析数据库返回的时间，于是一层正确的+08:00，在应用侧被硬生生掰回了UTC。这种“服务端正确、连接层错误”的问题最隐蔽。
5.2 Java应用怎么配连接串
Java连接串里建议显式加上serverTimezone参数：
jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=falseserverTimezone告诉驱动数据库服务器所在时区，驱动就按这个基准解释数据库返回的时间。useLegacyDatetimeCode=false在较新版本中也很常见，它让驱动尽可能使用服务器时区语义而不是JVM默认时区。如果使用的是mysql-connector-j8.0及以上版本，务必确认驱动行为和连接串参数的搭配。
这里也顺便说一下：如果应用和数据库都在东八区，直接把连接串里的serverTimezone设为+08:00或Asia/Shanghai，通常就能解决。不要小看一个连接串参数，它造成的偏移时间是实打实的。
5.3 Go、Python等语言侧同样要做时区约定
Java不是唯一受连接时区影响的场景。Go的数据库驱动，比如go-sql-driver/mysql，DSN里通常要设置loc参数，例如loc=Local或者loc=Asia%2FShanghai，否则解析时间可能落在UTC。Python的PyMySQL则常见于连接后立即执行SET time_zone = '+08:00'，或者依赖系统时区。这些语言差异背后是同一件事：应用必须知道数据库告诉它的时间是什么基准，否则任何一层误解都会产生偏移。
我的经验是：不要让每个应用开发者自己记时区规则，最好在初始化连接时统一设置，或者封装一个公共的数据访问层，把“连接后设置时间会话”这类操作收拢到一个地方。
5.4 防止双重偏移的铁律
所谓双重偏移，是指数据库已经存了正确值，应用在解析时间时按A时区理解，打印或展示时又按B时区格式化，最后结果既不是A也不是B。比如数据库中存的是东八区时间，驱动却按UTC解析，然后代码里又调用toLocalDateTime()转换了一次，时间就偏出两倍。
我的铁律是：全链路尽量只保留一个时区基准。要么数据库、连接串、应用运行环境全部用UTC，在展示层转成东八区；要么全部用东八区。最怕的是数据库用东八区、容器用UTC、JDBC参数不写、业务代码再自作主张转一次。四个环节只要有两个基准不一致，时间就一定会错。
6. 一套小而稳的时区治理清单：从系统到应用一步到位
6.1 排查顺序：先看系统，再看数据库，最后看连接
处理时区问题，我有一套固定的排查顺序，基本不会跑偏：
- 在数据库机器上执行
date，确认操作系统时区是不是业务期望的时区。 - 执行
SELECT @@system_time_zone, @@global.time_zone, @@session.time_zone;，确认MySQL三个值分别是什么。 - 执行
SELECT NOW(), UTC_TIMESTAMP();，确认实际时间偏移。 - 检查连接串和数据库驱动参数，确认连接层时区一致。
- 最后再看业务代码在读取和写入时间时有没有额外转换。
按这个顺序走，大多数“时间差8小时”的问题能在前四步定位。不要一开始就翻代码，代码在大多数情况下是无辜的。
6.2 修改三步走：急救、持久化、验证
- 急救：
SET GLOBAL time_zone = '+08:00';，主要为了不重启就让新连接生效。 - 持久化：配置文件写
[mysqld] default-time-zone = '+08:00'，或MySQL 8.0执行SET PERSIST time_zone = '+08:00';。 - 验证：按第4章的组合SQL执行一遍，并重启一次或至少确认持久化文件内容正确。
这个三步走方案可以覆盖绝大多数业务场景。如果你们公司有自动化运维平台，建议把时区值做成一个标准化基线，所有新装的MySQL实例默认就带default-time-zone = '+08:00'，而不是等出问题再改。
6.3 最后分享一个实际配置片段
下面是一段我在生产环境常用到的配置组合，它把操作系统、MySQL全局、会话默认值都收敛到了东八区：
[mysqld] default-time-zone = '+08:00'系统层面，我用系统初始化脚本统一设置：
timedatectl set-timezone Asia/Shanghai这样安排之后，新初始化出来的数据库实例，一出生就在正确的时区上，省掉了后续所有救火操作。如果你手头正好有一台已经跑了一段业务的数据库，只要确认业务没有依赖UTC做跨时区结算，就可以按本文的流程平滑调整。我实际处理过的项目里，按这套方法调整后，订单时间、日志时间、报表时间基本都能一次对齐。
