“我的数据库明明存的是北京时间，查出来怎么少了 8 个小时？”——这个问题我在不同场合被问了不下二十次，每次排查到最后，十有八九都是time_zone参数在作怪。MySQL 的时区参数表面上就一个单词，但它牵扯到操作系统时区、MySQL 全局配置、会话连接、JDBC 驱动、连接池，甚至 Docker 容器，任何一个环节错位，你看到的时间就会跟着错。这篇就把time_zone的前前后后一次讲透，从参数本身到配置方法，再到真正的踩坑现场。
不夸张地说，时区问题属于“不出事没人管，一出事一头雾水”的典型。之前维护过一套跨时区部署的业务系统，应用在北京、数据库在某个使用 UTC 标准的机器上，刚开始数据量小没感觉，等到报表统计按天分组时，发现凌晨 0 点到 8 点的数据全被算到了前一天，排查了大半天才定位到时区偏移。所以不管你是在本地开发环境、云服务器，还是在 Docker 容器里跑 MySQL，理解time_zone的工作原理都值得花十几分钟好好看看。
1. time_zone 到底是什么，为什么它会影响你看到的每一秒
不讲清楚原理，后面所有排查都是瞎蒙。先看 MySQL 里跟时区相关的几个核心概念，把它们放在一张表里对比，你就能明白整个时区体系是怎么运转的。
| 参数名 | 作用范围 | 默认值 | 含义 |
|---|---|---|---|
system_time_zone | 全局只读 | SYSTEM（跟随操作系统） | MySQL 启动时读取的操作系统时区，启动后不再自动变化 |
time_zone | 全局 + 会话 | SYSTEM | MySQL 内部的当前时区，SYSTEM表示跟随system_time_zone |
session time_zone | 仅当前连接 | 继承全局time_zone | 每个客户端连接建立时，从全局值继承并独立维护 |
注意看第三行，每个客户端连接都有自己的会话时区。也就是说，同一个 MySQL 实例，连接 A 看到的now()可能是北京时间，连接 B 看到的却可能是 UTC 时间，只要它们各自执行了不同的SET time_zone语句。这种设计本身是为了满足不同业务方在不同地域的显示需求，但也正因为“每个连接独立”，很多人在排查时容易蒙圈——明明在命令行改了时区，应用那边查出来却还是老样子，原因就是你只改了当前命令行连接的会话值，应用层的连接根本没收到变更。
1.1 系统时区、全局时区、会话时区，三者之间到底什么关系
创建一个新连接时，MySQL 会做一次“三级继承”。连接建立瞬间，会话时区直接取全局time_zone的值；而全局time_zone如果被设置成SYSTEM，那它实际取的就是system_time_zone，也就是操作系统时区。链路关系可以简单理解成：操作系统时区 → MySQL 全局时区 → 每个会话时区。
所以当你看到SHOW VARIABLES LIKE '%time_zone%'返回下面这种结果时，就能直接判断出问题在哪：
system_time_zone CST time_zone SYSTEMsystem_time_zone是 MySQL 启动时从操作系统抓取并固化的，之后你改了 Linux 系统时区，这个值也不会自动更新，必须重启 MySQL 才会重新读取。time_zone显示为SYSTEM，说明当前全局时区就是跟随系统时区。这也解释了一个高频现象：你在 Linux 上用timedatectl set-timezone Asia/Shanghai改了系统时区，但 MySQL 里查出来的时间还是旧的，因为 MySQL 进程没有重启，或者time_zone已经被显式修改成别的值了。
1.2 为什么有的字段差 8 小时，有的字段却好端端的
时区参数影响最大的数据类型是TIMESTAMP，而DATETIME基本不受影响。这俩长得像，但底层存储逻辑完全不同。
TIMESTAMP在存储时会把值从当前会话时区转换成 UTC 时间存进去，查询时再把 UTC 时间转回当前会话时区返回。也就是说，同一个TIMESTAMP值，会话时区是+08:00和+00:00，查询出来的字符串结果会相差 8 小时。DATETIME则完全不做任何转换，你存进去什么字符串，查出来就是什么字符串，跟时区参数无关。
这就导致一个很有意思的现象：业务表里既有create_time（TIMESTAMP）又有birthday（DATETIME），当数据库时区配置出错时，create_time显示的时间可能比实际时间少了 8 小时，而birthday显示完全正常。很多新手会以为是数据写错了，其实只是时区参数在TIMESTAMP字段上发生了“翻译偏差”。所以在设计表结构时，如果你明确希望时间字段不被任何时区因素干扰，DATETIME会更稳定；如果希望字段值能跟随会话时区自动适配不同地域用户，TIMESTAMP更合适。但这都建立在你真正理解了它们的差异之上。
2. 时区的查看、修改与持久化配置，一条龙实操
原理讲明白了，接下来进入动手环节。这部分不只教你命令怎么敲，更要告诉你每条命令背后的生效范围和坑点，否则很容易出现“改了好像没改”的错觉。
2.1 三步快速定位当前实例的时区状态
接到一个“时间不对”的反馈，我一般先执行下面三条 SQL，把现场情况摸清楚。
SHOW VARIABLES LIKE '%time_zone%'; SELECT @@global.time_zone, @@session.time_zone; SELECT NOW();第一条命令看system_time_zone和time_zone的整体情况；第二条命令分别确认全局和当前会话的时区值；第三条命令看当前会话视角下的当前时间。如果你这时顺手在 Linux 命令行执行date，对比一下 MySQL 返回的NOW()与系统时间是否一致，基本就能判断出问题出在数据库层还是应用层。这一步非常关键，它能帮你把排查范围迅速缩小。
比如说，MySQL 的NOW()返回2025-06-01 16:00:00，而 Linuxdate显示2025-06-02 00:00:00，说明数据库会话时区与系统时区存在 8 小时偏移，你再看一眼@@session.time_zone的值，十有八九是+00:00或UTC。反过来，如果两边显示一致，那问题就大概率出在 JDBC 连接串或应用代码上。
2.2 用 SQL 直接改时区，哪些生效哪些不生效
修改会话时区只对当前连接有效，典型的应用场景是做临时验证。例如你在命令行里执行：
SET time_zone = '+08:00';这条语句执行完之后，当前连接查NOW()就会切换成东八区时间，但其他任何连接都不受影响。所以在排查时，如果你怀疑是会话时区的问题，可以用它快速验证——把会话时区改成正确的值，再看业务查询时间是否恢复正常。如果恢复正常，说明应用连接创建后的时区设置不对，或者全局时区本身就是错的。
修改全局时区用的是：
SET GLOBAL time_zone = '+08:00';SET GLOBAL只对之后新建的连接生效，已存在的连接依然保留自己的会话时区。这是一条很容易被忽略的规则：你改了全局，但当前命令行这个连接以及所有应用里已经建立的连接，不会立刻感受到变化。如果想立刻让当前连接也生效，还要单独执行一次SET time_zone = '+08:00'。另外，SET GLOBAL的方式不会写入配置文件，MySQL 实例一旦重启，配置就被打回原形，所以这种方式只适合临时调整，不能作为最终解决方案。
2.3 配置文件持久化，重启也不怕
要让时区配置永久生效，需要修改 MySQL 配置文件。Linux 环境下常见路径是/etc/my.cnf或/etc/mysql/my.cnf，Windows 环境则是安装目录下的my.ini。在[mysqld]段落里加一行：
[mysqld] default-time-zone = '+08:00'注意：是default-time-zone，不是default_time_zone，MySQL 配置项里两种写法都兼容，但业界惯用的是连字符写法，和官方文档保持一致。修改完成之后需要重启 MySQL 服务才能生效。重启 MySQL 前建议先执行mysqladmin -u root -p ping确认实例当前状态，重启后用第 2.1 节的查询语句验证一遍，确认time_zone不再是SYSTEM。
如果你使用的是 Docker 版 MySQL，则可以在启动容器时通过--default-time-zone参数指定，例如：
docker run -d --name mysql8 \ -e MYSQL_ROOT_PASSWORD=root123 \ --default-time-zone='+08:00' \ -p 3306:3306 \ mysql:8.0不过更常见的做法是在容器内修改/etc/my.cnf后重启容器，或者直接把宿主机时区文件挂载进容器，这个我在第 4 部分详细讲。
2.4 命名时区与偏移量：两种写法，两套成本
MySQL 的time_zone支持两种赋值方式，一种是固定偏移量，比如+08:00、-05:00，另一种是命名时区，比如Asia/Shanghai、Europe/London。
偏移量的好处是零依赖，任何 MySQL 安装包都支持，只要字符串符合[+-]HH:MM格式就行。命名时区则更直观、更完善地考虑了夏令时等规则，但前提是 MySQL 的mysql库中已经导入了时区表数据。很多默认安装的 MySQL 实例没有导入时区表，这时你执行SET time_zone = 'Asia/Shanghai'会直接报错Unknown or incorrect time zone。解决方法是导入系统时区数据：
在 Linux 上，通常可以用以下方式导入：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysqlWindows 环境下则麻烦一些，需要去官网下载对应的时区表压缩包解压后再导入。如果你只需要“北京时间”这种固定 8 小时偏移，建议直接用+08:00就行，没必要给自己找麻烦去搞命名时区。但如果你面对的是需要按夏令时自动切换的海外业务，命名时区才是正确答案，靠手动偏移量维护夏令时切换会让你崩溃的。
3. 连接层才是重灾区：JDBC、连接池、ORM 的连环坑
很多人在数据库层面配置得好好的，结果应用连上来时间还是不对。原因很简单：应用与 MySQL 之间的连接层，JDBC 驱动也会参与时区解读，而且它的默认行为有时候和数据库不一致。这一层的问题通常比数据库本身更隐形，因为错误信息不明显，甚至完全不会报错，只是时间悄悄变了。
3.1 JDBC URL 里的 serverTimezone，到底该怎么写
Java 应用连接 MySQL 时，JDBC URL 通常会写类似这样的内容：
jdbc:mysql://localhost:3306/mydb?serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=trueserverTimezone参数的作用，是告诉 JDBC 驱动“MySQL 数据库端使用的时区是什么”。驱动在将 Java 的java.util.Date转换为 SQL 时间类型时，会参考这个参数来保证时间语义一致。如果这个参数不写，某些 MySQL 驱动版本（尤其是 5.1.33 之后到 8.x）会直接抛异常：The server time zone value 'CST' is unrecognized or represents more than one time zone——因为CST在 MySQL 里可以代表中国标准时间、美国中部时间、古巴标准时间等多个含义，驱动无法猜你到底想表达哪个。
注意我写的URL里有一个useLegacyDatetimeCode=true，这是很多老版本驱动的默认行为，它意味着驱动会尽量复用 JDBC 层的时间编码逻辑，而不是完全信任数据库时区。在 MySQL Connector/J 8.0.23 之后，官方开始推荐把useLegacyDatetimeCode设为false，并将serverTimezone显式指定，让驱动严格按数据库时区处理时间转换。很多老项目的连接串里只有serverTimezone=Asia/Shanghai，没写useLegacyDatetimeCode，实际上使用了默认的true，在跨时区部署时就会遇到时间不一致的问题。
从我的实测经验看，最稳妥的组合是：
jdbc:mysql://localhost:3306/mydb?serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false&useSSL=false&allowPublicKeyRetrieval=true前提是 MySQL 数据库时区确实已经设置为东八区。如果数据库用的是+08:00，驱动用的是Asia/Shanghai，由于二者都不涉及夏令时（中国已取消夏令时），结果是一致的。但如果数据库设置的是UTC而驱动连接串里写的是Asia/Shanghai，那时间就会偏差 8 小时，这个坑我下面案例部分会重点讲。
3.2 连接池和 ORM 框架的隐藏时区逻辑
你以为搞定了 JDBC 连接串就万事大吉了？太天真了。连接池和 ORM 框架还有自己的“小九九”。
以 HikariCP 为例，它会缓存连接配置，连接池初始化时读取 JDBC URL 里的参数。如果你在代码里手动创建连接池，但 URL 里没写serverTimezone，而数据库端时区又不是默认值，那连接池里的连接在创建时会得到一个默认的时区处理逻辑，这可能导致与数据库端不一致。最典型的问题是：连接池中的连接被不同线程复用，某个线程在连接上执行了SET time_zone，之后这个连接归还到池中，另一个线程拿到它时，会话时区还是上一次改过的值。所以绝不建议在代码里对业务连接随意执行SET time_zone，这类操作应该在连接池初始化时统一配置。
再说说 ORM 框架。MyBatis 或 MyBatis Plus 本身不直接处理时区，它依赖于 JDBC 驱动的参数设置。而 Hibernate 则有自己的时区处理机制，可以通过配置项hibernate.jdbc.time_zone来指定持久化时区。如果你用了 Hibernate，同时又在 JDBC URL 里配置了serverTimezone，两者之间不一致时也会有隐患——Hibernate 6.x 版本对时区的默认逻辑与 5.x 不同，升级框架版本后出现时间偏差，不少是这方面的原因。所以排查时间问题时，如果数据库、JDBC URL 都看了还找不到原因，请把 ORM 框架的参数也纳入检查范围。
我见过一个真实场景：数据库时区是+08:00，JDBC URL 里写的是serverTimezone=UTC，Hibernate 又配置了hibernate.jdbc.time_zone=Asia/Shanghai。结果查询时，数据从 MySQL 出来先按 UTC 解释，再被 Hibernate 转成东八区，时间完全错乱。项目里有注释写着“当时为了兼容某个老接口加上去的”，但没有人真正验证过这个配置是否仍然必要。
3.3 应用服务器、数据库、连接串，到底按谁的时间来
这里我建议所有团队都确定一套“时区黄金法则”：应用程序服务器、数据库服务器、JDBC 连接串、操作系统，统一采用一个时区（推荐Asia/Shanghai或+08:00）。不要出现应用在UTC、数据库在+08:00、连接串却写Asia/Shanghai这种互相打架的情况。
如果业务确实跨地域，比如国内和美洲团队共用一套系统，更推荐的做法是：数据库统一使用+00:00（UTC）存储，应用层在展示时根据用户所在时区做转换。也就是说，让“存储层保持中性、接入层做适配”，这样既保证数据的一致性，又避免为不同的办事处分别维护数据库实例或修改数据库时区配置。这种方案需要开发团队对时间处理有足够成熟度，但一旦落地，几乎不会再出现“时间差 8 小时”这类低级的线上事故。
4. 实战复盘：从差 8 小时到差 13 小时，这些案例你可能也会遇到
理论讲再多，不如看几个真实的排查过程。下面这几个案例都是我在实际工作中或帮朋友排查时遇到的，覆盖面比较广，从 Docker 环境到经典 TIMESTAMP 问题都有，你可以直接对照自己的场景。
4.1 案例一：Docker 装 MySQL，容器时间和宿主机差 8 小时
Docker 部署 MySQL 的场景现在非常普遍，但容器内时区默认是 UTC，和宿主机经常不一致。具体表现为：宿主机执行date显示北京时间，进入容器执行date显示的却是 UTC 时间，MySQL 里的NOW()也跟着差了 8 小时。
排查思路分两层。第一层是容器内系统时间不对，第二层是 MySQL 实例的time_zone又继承了这个错误时间。解决办法有好几种，按推荐程度排序如下：
方案一，启动容器时挂载时区文件：
docker run -d --name mysql8 \ -v /etc/localtime:/etc/localtime:ro \ -e TZ=Asia/Shanghai \ -e MYSQL_ROOT_PASSWORD=root123 \ -p 3306:3306 \ mysql:8.0注意：容器内需要安装tzdata，否则TZ环境变量可能不生效。MySQL 官方镜像基于不同发行版，处理方式有细微差别，如果你用的是mysql:8.0，基本自带时区数据，直接这样做没问题。
方案二，在容器启动后进入容器修改 MySQL 配置，然后重启容器，这种方法也能解决，但不推荐作为标准流程，毕竟每次重新创建容器都要再操作一遍。方案三，直接忽略操作系统时区，只修改 MySQL 的default-time-zone为+08:00，这也是可行的，但容器内应用如果不只跑 MySQL，可能还会遇到其他程序的时间问题。
判断问题必须分清是“容器系统时区”还是“MySQL 参数时区”。即使你把 MySQL 参数设为+08:00，容器里date显示的依然可能是 UTC 时间，因为这是两层概念。我建议在 Docker 部署时就一次性把容器时区、MySQL 参数都设置好，不要图省事只改其中的一半。
4.2 案例二：TIMESTAMP 字段查出来比实际少 8 小时，DATETIME 却正常
一个朋友排查了很久，说数据库里create_time查出来时间是2025-07-01 12:00:00，但业务系统真实写入时间应该是2025-07-01 20:00:00，而另一个字段update_time却是正常的。刚开始他怀疑是数据写错，但我让他查一下字段类型，create_time是TIMESTAMP，update_time是DATETIME，问题就清晰了。
TIMESTAMP在存储时，MySQL 会根据会话时区把时间转成 UTC 再存进去。如果会话时区是+08:00，写入20:00:00时实际存的是12:00:00（UTC）。查询时再把12:00:00从 UTC 转回+08:00，正常情况显示还是20:00:00。现在显示12:00:00，说明查询会话的时区是+00:00，也就是查询时的会话时区没有跟着数据库全局时区走。
再往深挖，发现朋友的 Java 代码里用了 MyBatis-Plus，连接池是 Druid。Druid 在初始化连接时默认会执行一个初始化 SQL，大概长这样：SET time_zone = '+00:00'，这个逻辑来自 Druid 的connectionInitSqls配置。他又在application.yml里配了serverTimezone: UTC，导致 JDBC 驱动读取时也按 UTC 处理。本来数据库是正确的东八区，却因为连接层的配置被强行“翻译”成了 UTC，时间自然不对。
这个案例的教训是：TIMESTAMP 字段和连接池时区配置强相关，排查时要把“数据库全局时区 + 数据库会话时区 + 连接池初始化 SQL + JDBC 驱动参数”四条线一起捋。DATETIME 字段因为不做转换所以没事，容易让人忽视问题源头。
4.3 案例三：为什么查出来的时间差了 13 个小时
有个朋友说他们的时间偏差不是 8 小时，而是 13 个小时。我第一反应是夏令时，但国内业务不涉及夏令时，那就可能是跨时区传输。查到最后发现，应用服务器部署在美国西部（PDT，夏令时期间为 UTC-7），数据库在东八区。应用服务器把本地时间2025-07-01 05:00:00（PDT）传给 JDBC，JDBC 按serverTimezone=America/Los_Angeles解析后转成 UTC，然后数据库东八区再转一遍，最终显示2025-07-01 18:00:00，一来一回差了 13 小时。
这种情况下，光是“把连接串里的serverTimezone改成Asia/Shanghai”还不够，因为应用服务器本身的系统时间语义已经不对了。最根本的解决方案还是统一存储标准——要么全部用 UTC 存储，要么全部用东八区，并确保应用服务器、数据库、JDBC 驱动三者的时区设置完全一致。这个案例也提醒我们，时区排查不能只看数据库一台机器的配置，应用部署所在地的时区影响有时更大。
4.4 常见问题排查速查表
| 现象 | 可能原因 | 排查与解决建议 |
|---|---|---|
NOW()比系统时间少 8 小时 | MySQLtime_zone为SYSTEM且系统时区错误，或被显式改为+00:00 | 查询SHOW VARIABLES LIKE '%time_zone%'，与操作系统date对比，修改配置并重启 |
SYSTEM值一直是旧时区 | 修改了 Linux 时区但 MySQL 没重启 | 重启 MySQL 服务，或直接设置default-time-zone |
设置Asia/Shanghai报错 | 时区表未导入 | 使用mysql_tzinfo_to_sql导入，或改用+08:00 |
| Java 应用时间比数据库少 8 小时 | JDBC URL 缺少serverTimezone或写成UTC | 检查连接串，显式设置serverTimezone=Asia/Shanghai |
| 连接池连接出现随机时区不一致 | 业务代码中有人执行SET time_zone | 检查连接池初始化和业务代码，统一在连接初始化时设置 |
| Docker 容器时间与宿主机不一致 | 容器内时区默认 UTC | 挂载/etc/localtime，设置TZ=Asia/Shanghai |
| 同一表不同时间字段表现不一致 | TIMESTAMP与会话时区相关，DATETIME不受影响 | 查字段类型，确认会话时区设置 |
| 海外服务器时间偏差不是 8 小时 | 应用服务器与数据库跨时区，存在夏令时 | 统一存储时区标准，或全部使用 UTC |
5. 一些值得长期坚持的时区管理习惯
最后分享几个我在实际项目中积累的操作习惯，不算什么高深技巧，但确实能帮你少踩坑。
第一个习惯：在所有数据库运维脚本和项目 README 里，明确记录当前的时区约定。很多人配置完时区就完事了，等半年后另一个同事接手，看到default-time-zone = '+08:00'根本不知道是刻意配置还是某次调试遗留。我在团队内部会强制要求在每个环境的部署文档里写明“数据库时区：东八区（+08:00），不要修改”，省去了很多沟通成本。
第二个习惯：数据库连接统一走连接池，业务代码禁止随手执行SET time_zone。如果确实需要特定时区，连接池的connectionInitSqls里统一配好，不要让业务代码各自为政。这一点对连接复用频繁的高并发系统尤其重要，不然一个连接被改乱，影响面就是一条线上链路上的所有后续请求。
第三个习惯：开发环境、测试环境、生产环境的时区设置保持一致。很多 bug 在本地复现不了，就是因为本地 MySQL 时区写的是默认SYSTEM，而测试环境用了+08:00，生产环境又用了UTC。统一从环境初始化阶段就把时区定下来，后面排查问题可以少想一层。
第四个习惯：改完时区配置之后，一定要用mysqladmin或新建连接验证，不要「觉得应该生效了」。方法很简单，重新打开一个命令行连接执行SELECT NOW()，再和系统时间对比一下，同时用SHOW VARIABLES LIKE 'time_zone'确认全局值。每次改动花 10 秒钟验证一下，比事后排查一个小时的强太多了。
time_zone 这个参数看起来简单，但它横跨操作系统、数据库、连接层三层体系，还可能波及到容器部署和跨时区网络环境。把它真正吃透，不仅能帮你解决“时间少了 8 小时”这类经典问题，更能在系统设计阶段就避开相应的设计隐患。如果看完你还有拿不准的细节，建议直接在本地搭个 MySQL 实例，改几次时区设置，查几次NOW()和不同类型字段的显示结果——这种亲手验证留下的感觉，比看任何文章都管用。
