MySQL 时区参数 time_zone 详解
说出来你可能不信，我见过太多团队在排查"时间差了8小时"的线上问题时，第一反应是检查应用服务器的时区设置，第二反应是看连接字符串里的serverTimezone参数，折腾半天最后才发现数据库会话的time_zone压根不是自己以为的那个值。MySQL里的时间问题之所以难搞，就在于时间数据从写入到读取，中间要经过好几层"翻译"，任何一层的时区语义和你预期的不一致，最终呈现出来的时间就会和你"以为"的不一致。
这篇文章就专门把MySQL时区参数time_zone讲透——它是怎么影响连接会话的、和系统时区是什么关系、为什么同一个库里不同的客户端查出来的时间会不一样，以及在实际的生产环境里应该怎么配置才不会踩坑。无论你是后端开发、DBA还是运维，把这套机制理解清楚，以后碰到类似问题基本都能一眼定位。
1. 先厘清 time_zone 和 system_time_zone 的关系
1.1 两个参数各自管什么
很多人第一次查MySQL时区相关参数时，会看到两条记录，一条是system_time_zone，一条是time_zone，名字很像，经常被混为一谈。我先把这两者的分工说清楚。
system_time_zone是MySQL在启动时从操作系统读取的时区，它表示的是服务器操作系统当前的时区。这个值在MySQL实例启动之后就不会再变了，哪怕你后来改了操作系统的时区配置，MySQL也只会记住启动那一刻的值。它的作用主要是作为"系统时区"的参照，当time_zone被设置为SYSTEM时，MySQL就会拿这个值作为会话时区。
time_zone则是当前会话（或全局）正在使用的时区，它的默认值是SYSTEM，意思就是"跟随系统时区"。你可以通过SET time_zone = '+08:00'或者SET time_zone = 'Asia/Shanghai'这样把它改成具体的时区。全局设置会影响后续新建立的连接，会话级设置只影响当前连接。
查看这两条参数的SQL很简单：
SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;我见过一个很有意思的案例：某公司的MySQL部署在东京的机房，操作系统时区是JST（东九区），但业务方一直以为数据库是北京时间。于是他们发现某些服务记录的时间比预期快了1小时。查下来发现system_time_zone是JST，time_zone默认跟随SYSTEM，自然也就是东九区。而业务代码里却按照北京时间去理解，差值就是这么来的。
1.2 SYSTEM 这个默认值埋的坑
问题最大的就是SYSTEM这个默认值。它看起来人畜无害——"我就跟着系统走呗"——但在生产环境里，系统时区往往是不可控的。
举个例子：你的DBA在部署数据库时，服务器初始化的镜像里/etc/timezone是UTC，MySQL启动后system_time_zone就被固定成了UTC。后来运维觉得服务器在本地部署，应该用本地时间，于是把系统时区改成了Asia/Shanghai。这时候MySQL实例的system_time_zone依然是UTC，但数据文件里已经混入了不同时区语义的数据，新旧数据之间就可能出现混乱。
更隐蔽的情况是容器化部署。容器的主机时区、镜像里的时区配置、MySQL的时区参数，这三者是可以互不相同的。你很难保证所有环境里的system_time_zone都是同一个值。
所以我的建议是：生产环境不要依赖SYSTEM，直接把time_zone显式设置为一个固定的时区偏移或具名时区。这样即使运行环境发生变化，数据库内部的时区语义也是稳定一致的。看一个实际配置示例：
[mysqld] default-time-zone = '+08:00'或者用具名时区（前提是加载了时区表）：
SET GLOBAL time_zone = 'Asia/Shanghai';这里有个细节要注意：如果你用的是+08:00这样的偏移量，那么它只影响日期的加减转换，不涉及夏令时等规则；如果你用Asia/Shanghai这种具名时区，那么MySQL会严格按照该时区的规则来，包括历史时间点的夏令时偏移。对于绝大多数国内业务，用+08:00就够了，省得还要加载时区表。
2. timestamp 和 datetime 的存储语义差异：时区问题真正的源头
2.1 为什么同样的数据在不同时区下读出来不一样
这是整个时区问题里最核心、也最容易被忽视的部分。MySQL里有两个常用的日期时间类型，TIMESTAMP和DATETIME，它们的最根本区别并不只是取值范围的大小，而是存储方式完全不同。
TIMESTAMP类型在内部存储时，会把值转换成UTC时间（或者说，把session时区下的时间转换为UTC时间）来保存。读取的时候，再做一次逆转换，从UTC转回当前会话的时区。也就是说，TIMESTAMP本身存的是一个"时间点"，它会跟随会话时区的变化而变化。
DATETIME类型则是字面量存储——写入的是什么值，读出来就是什么值，完全不涉及时区转换。它更接近一个"墙上时间"的概念，不带时区语义。
这句话怎么理解？我们看一个具体的例子。假设当前会话时区是+08:00，执行：
CREATE TABLE t_time ( ts TIMESTAMP NULL, dt DATETIME NULL ); INSERT INTO t_time (ts, dt) VALUES ('2025-06-01 12:00:00', '2025-06-01 12:00:00');此时，ts这一列存入的是UTC时间2025-06-01 04:00:00（减8小时转成UTC），dt这一列存入的是2025-06-01 12:00:00原文。
接下来我们把会话时区改成+00:00再看看结果：
SET time_zone = '+00:00'; SELECT ts, dt FROM t_time;你会看到：
ts显示为2025-06-01 04:00:00——因为它内部按UTC存，读出来要转换到当前会话时区+00:00，所以显示的就是UTC时间。dt依然显示2025-06-01 12:00:00——它不带时区语义，原样返回。
这个例子完美展示了为什么同样的数据，在不同时区设置下读出来会不一样。只要数据类型是TIMESTAMP，它的显示值就永远跟着会话时区走。
2.2 实际业务中该选哪种类型
理解了这个差异之后，选型就有了依据。我简单梳理一下：
| 对比维度 | TIMESTAMP | DATETIME |
|---|---|---|
| 存储空间 | 4字节 | 8字节（MySQL 5.6.4前为8字节，带小数时更多） |
| 取值范围 | UTC范围有限，约为1970~2038年 | 范围更大，1000-01-01到9999-12-31 |
| 时区转换 | 自动跟随会话时区 | 不转换，存什么取什么 |
| 默认值 | 支持DEFAULT CURRENT_TIMESTAMP | 也支持，但历史版本有差异 |
| 适用场景 | 记录事件发生的绝对时间点 | 记录日历时间、生日、排期等不依赖时区的信息 |
如果业务里要记录的是一条"事件发生时刻"，比如订单创建时间、日志时间、操作记录时间，那用TIMESTAMP是合理的——因为它真正做到了"全球统一时间点"，无论哪个时区的客户端来查，转换后都是客户端本地的墙钟时间。当然前提是客户端连接的会话时区设置正确。
如果业务里要记录的是"某个日历上固定的时间"，比如课程表"每周三14:00上课"、生日"1995-08-17"、促销活动"12月25日全天"，那应该用DATETIME。因为这类时间不应该因为客户端时区不同就变来变去。
一个很典型的失误是把用户设置的提醒时间存成TIMESTAMP，然后在不同时区的设备上读出来发现完全不对——本身TIMESTAMP的设计意图就是"统一时间点后的本地化展示"，它恰恰不适合这种"固定墙上时间"的场景。
2.3 UTC到底是怎么参与运算的
有人会问：MySQL把TIMESTAMP存成UTC，这个UTC是基于哪里的？是不是服务器时区转的？
准确讲，整个过程是：
- 写入时：
TIMESTAMP列收到一个字符串/日期字面量，MySQL按照当前会话时区把它解释成一个墙上时间，然后换算成UTC存入内部。 - 读取时：MySQL把内部存储的UTC值，按照当前会话时区换算成墙上时间返回给客户端。
所以决定结果的不是服务器系统时区，而是会话的time_zone参数。如果会话时区设置正确（通常是业务的本地时区），那么写入和读取都能得到符合预期的值。如果会话时区设置错了，比如业务在北京时间，但会话时区被设成了UTC，那么写入的时候就会多8小时或者少8小时。
我用一个例子验证这一点。假设服务器系统时区是UTC，但你在会话里做了：
SET time_zone = '+08:00'; INSERT INTO t_time (ts) VALUES ('2025-06-01 12:00:00');然后换一个会话：
SET time_zone = '+08:00'; SELECT ts FROM t_time;结果是12:00:00。注意，服务器系统时区是UTC，但因为会话时区是东八区，写入和读取都按东八区来，所以数据完全一致。真正决定行为的，是会话时区而不是服务器时区——这一点常常颠覆很多人的直觉。
3. 配置与函数调用链：从连接器到SQL语句都会影响最终结果
3.1 全局配置、会话配置和连接器参数的优先级
在生产环境里，一个SQL查询的时间结果实际上被多层因素影响，从数据库全局配置，到连接会话，再到客户端连接器的参数，层层叠加。我把它们的优先级按从小到大排列：
- MySQL全局参数
@@global.time_zone：实例级默认值，只影响新建立的连接。 - 连接会话参数
@@session.time_zone：当前连接生效，优先于全局配置。应用程序可以通过连接初始化SQL或连接器参数修改它。 - 连接器/驱动参数：比如JDBC连接串里的
serverTimezone、ODBC里的时区设置。连接器本身有时也会做转换，这就可能和数据库端产生双重转换。
一个最常见的"双重转换"坑是：应用服务器时区是东八区，数据库服务器时区是UTC，JDBC的serverTimezone参数没有设置（或者设置错了）。此时连接器可能按照本机时区东八区解释从数据库拿到的DATETIME字符串，而数据库返回的值本身是按UTC会话时区生成的，两边各加了一次偏移，时间就对不上了。
我的经验是，在JDBC连接串里直接指定serverTimezone=Asia/Shanghai，并保持MySQL会话的time_zone也是+08:00，两者对齐，能省掉绝大多数远端连接的时区坑。
3.2 常见函数受时区影响的行为
有几个常用的时间函数，取值结果也和会话时区直接相关，这里列一下：
NOW()、CURRENT_TIMESTAMP、LOCALTIME、LOCALTIMESTAMP：返回当前会话时区的墙上时间。同一个物理时刻，不同时区下返回的字符串不同。CURDATE()、CURRENT_DATE、CURTIME()：同理，跟随会话时区。SYSDATE()：描述的是语句执行的时刻，它和NOW()的主要区别在于获取时间点的时机，但时区行为上同样跟随会话时区。FROM_UNIXTIME()：把Unix时间戳转换成日期时间时，使用的是当前会话时区。UNIX_TIMESTAMP()：反向操作，把日期时间转成Unix时间戳时，也是按照当前会话时区来解析这个日期时间的。
这意味着什么？如果你在SQL里用了WHERE create_time >= FROM_UNIXTIME(1748764800)这样的写法，而会话时区设置不同，实际过滤的时间范围就会差上8个小时。同一段SQL，在不同时区的会话里跑，查出来的数据可能完全不一样。
所以团队内部如果有统一的规范，就一定要统一"所有数据库连接显式设置时区"这件事。不能今天这个服务连的是+08:00会话，明天那个服务连的是SYSTEM（又可能是UTC），那么所有跟时间相关的SQL行为都不再可预期。
3.3 我推荐的生产配置组合
如果你问我生产环境里最省心的配置是什么样的，我会给出这样一套组合：
- 所有MySQL实例统一设置
default-time-zone='+08:00'（或你业务实际所在的时区），不使用SYSTEM。 - 应用连接串里显式设置
serverTimezone=对应的值，不依赖默认推断。 - 业务代码里统一使用UTC时间戳或时间字符串写入数据库，由数据库层负责时区转换展示——或者反过来，代码层做转换，数据库全部存UTC，二者取其一，不要两头都转。
第3点是很多人忽略的关键。最怕的是代码里先按本地时间转换了一遍，数据库会话时区又是另一个值，写入TIMESTAMP列时又转了一遍，最后存进库里的"时间点"就完全错了。这属于典型的重复转换。
我自己的习惯是：写入数据库的时间统一用业务服务器所在时区的墙上时间字符串，数据库会话时区也设置为同样的时区；读取出来后交给前端再按用户偏好时区展示。这样链路清晰，每层只负责一次转换。
4. 线上一次"时间错乱"的完整排查复盘
4.1 故障现象回顾
有一段时间我们线上某核心服务偶发出现"创建时间和支付时间倒挂"的诡异问题——日志里显示订单创建于23:50，支付回调时间却是次日02:30，但业务上支付不可能发生在创建之前。
一开始所有人都觉得是入参数据本身错了，拿着日志反复核对，发现不对劲：同一个订单，在MySQL客户端查出来是一个时间，在Redis缓存里查出来又是另一个时间，在应用日志里打印的时间又不一样。
4.2 排查链路
第一步，看应用日志的时间。日志框架输出的时间通常受日志框架自身的时区设置影响，这里显示的是北京时间。那么订单创建时间就是北京时间23:50。
第二步，查数据库里实际存的值。用SELECT ts, dt FROM orders WHERE order_id = ...这条SQL，结果发现ts列显示的是次日02:30。这一步就很奇怪了——如果会话时区是北京时间，这个值应该和业务日志一致才对。
第三步，检查数据库连接会话时区。执行SELECT @@session.time_zone;，结果返回了SYSTEM。于是继续查@@global.time_zone，还是SYSTEM。最后直接查操作系统时区date命令，发现服务器被设置成了UTC。
问题的根源这时候就清楚了：应用服务器在北京时区，应用日志自然输出北京时间；数据库服务器在UTC，数据库会话时区又是SYSTEM跟随系统——UTC。应用在写入TIMESTAMP列的时候，MySQL按照UTC会话时区去解析应用传来的'2025-06-01 23:50:00'字符串，认为这就是UTC时间，于是存进去的UTC时间多出了8小时。读取时也按UTC返回，于是显示成了'2025-06-02 07:50:00'。客户看到的是应用日志里的23:50，数据库里实际存的时间点却被错误地加了8小时偏移，后面的回调时间自然乱了套。
第四步，验证。把会话时区改成北京时间再查：
SET time_zone = '+08:00'; SELECT ts FROM orders WHERE order_id = ...;数据立刻变成了2025-06-01 23:50:00，和应用日志一致。到这里就完全确认了问题原因。
4.3 修复方案与事后改进
修复分两步。第一步是让所有连接都显式使用北京时区：
SET GLOBAL time_zone = '+08:00';同时修改配置文件：
[mysqld] default-time-zone = '+08:00'第二步是排查存量数据里那些"被错误当UTC存的记录"。理论上说，如果数据已经是错误的时间点（等于把北京时间字符串当成了UTC来解析，存进去的UTC时间实际早了8小时），那这些数据即使换了会话时区，读出来也依然会比真实事件时刻早8小时。所以凡是用TIMESTAMP列且明确表示"北京时间事件时刻"的存量数据，都要按时间范围逐条或脚本批量做补偿修正。这个过程比较痛苦，也提醒我们：时区配置应该在建库、上线第一天就定好，事后修数据是最坏的方案。
4.4 这起故障给我们的三条教训
第一，不要依赖SYSTEM这个默认值。你以为"跟随系统"很省心，但系统时区不由数据库团队掌控。容器换环境、镜像重做、运维改配置，都可能在不知情的情况下改变system_time_zone。
第二，连接器连接串里的时区必须显式声明。在很多连接池框架里，数据库连接的初始化SQL是可以定制的，比如Druid的connectionInitSqls可以配置：
SET time_zone = '+08:00'或者直接在JDBC URL里写serverTimezone=Asia/Shanghai。我强烈建议两条路都走，从数据库和服务端双重对齐。
第三，时间相关的问题要有"可观测性"。把连接初始化后实际生效的@@session.time_zone定期采集上报，发现不是预设值时立刻告警。这个监控成本很低，但能避免问题隐藏很久才暴露。
5. 还有什么会被时区影响：日志、备份、复制链路上的细节
5.1 binlog与主从复制中的时区表现
MySQL的TIMESTAMP在主从复制里通常以UTC秒数记录，所以从库即使在不同时区的机器上，复制过来的数据在语义上依然是同一个时间点，这一点是安全的。真正要小心的是基于语句的复制（Statement Based Replication）。如果主库执行了类似INSERT INTO t VALUES (NOW())这样的语句，从库在回放时也会执行同样的语句，而NOW()的结果取决于从库自己的会话时区。如果主从两边的时区配置不一致，从库写入的时间点就会和主库不一致。
所以主从架构里，时区配置一定要作为基线环境的一部分，跟字符集、排序规则一样，纳入部署规范。我见过有团队在从库上不小心改了时区，结果半个月后做数据对比才发现大量TIMESTAMP字段和主库差出一截。查起来极其头疼，比数据丢失还难缠。
5.2 慢查询日志和通用日志的时间戳
MySQL的慢查询日志、通用日志里的时间戳，默认也是按照会话/全局时区输出的。如果time_zone没有正确设置，你在和开发同学一起排查慢SQL的时候就会发现日志时间和前端看到的请求时间对不上，明明同一个请求，两边时间差了8小时，排查进度瞬间卡住。
对此，除了设置好时区之外，还建议在MySQL 5.7及以上版本里显式开启log_timestamps参数：
[mysqld] log_timestamps = SYSTEMlog_timestamps的取值可以是UTC或SYSTEM，默认是UTC。如果你的日志收集系统按本地时间对齐，那最好显式设为SYSTEM，避免日志时间和会话时区认知不一致。这个参数非常容易被忽略，但它对排查跨系统时间问题至关重要。
5.3 连接池初始化SQL的兜底写法
最后分享一个"抄作业"级别的配置。使用连接池（比如Druid、HikariCP）时，可以在连接初始化阶段强制设置时区，这样哪怕DBA某天改了全局时区，你的应用连接也依然能保持固定的时区语义，不会因为基础设施调整而被影响到。
以Druid为例，配置里加：
spring: datasource: druid: connection-init-sqls: - "set time_zone = '+08:00'"HikariCP可以用connectionInitSql：
spring: datasource: hikari: connection-init-sql: "set time_zone = '+08:00'"这样即使MySQL全局配置被调整成非预期的时区，应用侧也能在每次建立新连接时强制改回来，整体行为依然可控。
MySQL的时区问题看起来只是一个小参数，实际上它牵涉到存储引擎的存储语义、SQL函数的取值行为、连接器协议、日志采集、主从复制多个环节。很多人花了大量时间在业务代码里"纠正8小时偏差"，其实正确的解法往往只是把一个参数从默认值改掉，再保持链路各层时区一致。
我个人在实践中最深的体会是：时区不是一个"配置一次就永逸"的东西，它更像一个贯穿全链路的契约。数据库、连接池、应用服务器、日志框架、前端展示，每一层都要明确知道自己使用的时区是什么。只有这个契约在所有环境里都达成一致，时间数据才真正可靠。希望这篇梳理能帮你把这条契约的每一环都牢牢握在手里，少踩几个"8小时"的坑。
