1. 时区问题为什么总是绕不开先搞清楚 time_zone 到底在管什么很多 MySQL 使用者都遇到过这种场景程序里插入一条记录存进去的时间是对的查出来却差了 8 个小时或者服务器时间明明正常但数据库里 NOW() 返回的结果和操作系统对不上。这类问题十有八九是 time_zone 参数没配明白。它不复杂但牵涉面很广——从 SQL 函数的返回值到连接驱动的时区协商再到 TIMESTAMP 类型的存储逻辑全部会被这个参数影响。这篇文章直接把 time_zone 参数拆开讲清楚包括取值规则、配置方式、对数据存储和查询的影响以及和 JDBC 连接串的配合问题。1.1 MySQL 时区的三层结构系统时区、全局时区、会话时区MySQL 的时区逻辑并不是单一的一个值而是分了三层。最底层是系统时区system_time_zone它是在 MySQL 启动时从操作系统读取的表示服务器所在物理机的时区。这一层是只读的启动后不会自动跟着系统改。第二层是全局时区time_zone这个变量控制了所有新建立的连接的默认时区可以用 SET GLOBAL 或者启动参数修改。第三层是会话时区session time_zone每个客户端连接都会继承全局时区的值但也可以在当前会话内单独覆盖只影响这一个连接。实际查的时候用三条 SQL 就能看到当前状态SELECT global.time_zone; SELECT session.time_zone; SELECT system_time_zone;一般刚装完的 MySQLglobal.time_zone 会显示 SYSTEM意思就是“跟随系统时区”。而 system_time_zone 则会显示操作系统实际时区比如 CST这里的 CST 在中文语境下通常是中国标准时间即 UTC8或者 UTC。MySQL 官方文档里对 SYSTEM 的解释是从操作系统继承时区。但这里有个坑如果操作系统时区本身配置得比较随意比如有些云主机默认是 UTC那 MySQL 的 SYSTEM 也就跟着变成 UTC然后应用侧如果按东八区做转换就会出现小时级别的时间偏移。1.2 为什么搞错时区会导致时间“穿越”可以这样理解time_zone 是 MySQL 对外展示时间的“翻译器”。MySQL 内部存储的其实是 UTC 时间戳对 TIMESTAMP 类型而言查询时根据当前会话时区换算成“本地时间”返回。如果会话时区是 08:00那么内部 UTC 时间会加上 8 小时给你看如果会话时区是 00:00就直接把 UTC 给你看。同一个内部值在不同会话时区下显示出来的“墙上时间”不同这才是很多人觉得数据穿越了的真正原因。再举个例子。你在北京时间 14:00 插入一条 TIMESTAMP 数据MySQL 内部存的是 06:00 UTC。另一个人用 UTC 时区连接同一个库查出来这条数据的时间是 06:00他可能会认为你存错了。其实两边都没错只是翻译时区不同。很多线上的“时间对不上”问题往往就是应用服务器设置了东八区数据库全局时区是 SYSTEM 且系统是 UTC或者反过来最后导致业务侧拿到的时间要么多了 8 小时要么少了 8 小时。2. time_zone 参数的取值规则与配置方法2.1 支持哪些写法数值偏移、命名时区、SYSTEMtime_zone 的合法值比想象中多。最常用的两种一种是直接写偏移量比如 08:00、-05:30这种写法不需要加载时区表解析效率高也最容易理解另一种是写命名时区比如 Asia/Shanghai、UTC、America/New_York这种写法依赖于 MySQL 自带或你手动加载的 mysql.time_zone_name 表。还有一种特殊值是 SYSTEM表示跟随系统。如果要用命名时区前提是时区表不能被清空。MySQL 安装后默认可能没有填充时区表只有 SYSTEM 和 UTC 这类简单值可用。加载方式是在操作系统里执行mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql执行完成后mysql 库的 time_zone 相关表里就有了几百条时区记录。这时设置 Asia/Shanghai 就不会报错。如果你只是用偏移量 08:00不需要加载时区表。偏移量写法有个细节小时和分钟之间必须带冒号0800 这种写法是不被接受的。同时分钟部分理论上只能是 00、30、45 这些实际时区用到的值虽然 MySQL 并没有严格校验但乱写会导致计算结果不符合任何现实时区建议保持规范。2.2 全局配置与会话级覆盖SET GLOBAL 和 SET SESSION运行时的配置方式有两种一个管全局一个管会话。SET GLOBAL 只影响之后新建的连接不会改变当前已经存在的会话。SET SESSION 只影响当前连接。注意如果配置了全局时区但对已经在跑的长连接没有生效业务侧连接池里那些旧连接依然使用旧值必须重连才能拿到新的全局值。这一点经常被忽略改完 my.cnf 重启 MySQL 反而更稳妥。实操命令-- 全局视角改为东八区 SET GLOBAL time_zone 08:00; -- 当前会话改为 UTC SET SESSION time_zone 00:00;如果你有 SUPER 权限或者拥有动态变量设置权限执行 SET GLOBAL 不会有问题。但要注意这个修改不会持久化到配置文件MySQL 一旦重启就会回到配置文件中设置的值。要想重启后依然生效需要同步修改 my.cnf 或启动参数。2.3 配置文件 my.cnf 与启动参数生产环境推荐直接在配置文件里固定时区避免运行时改来改去导致混乱。在 [mysqld] 段添加[mysqld] default-time-zone 08:00用命名时区也可以[mysqld] default-time-zone Asia/Shanghai但注意如果用了命名时区必须保证时区表已加载否则 MySQL 启动时会直接报错退出。更稳妥的做法是用数值偏移不依赖时区表也不依赖操作系统的时区设置彻底消除环境差异。启动参数对应的是 --default-time-zone08:00效果和配置文件一致。还有个容易被带偏的参数叫 time_zone 的“兄弟”——system_time_zone。它只能在启动时由系统指定运行期你改不了。有些文章建议把系统时区改成 UTC然后让 MySQL 的 time_zone 也设成 00:00这样内部存储更“纯净”。这确实是一种设计思路但前提是应用层也统一按 UTC 处理否则用户看到的时间就会很别扭。我个人的建议是全链路能统一最好统一不了就以业务展示端为准让 MySQL 的会话时区和应用连接参数保持一致。3. time_zone 对 NOW()、CURRENT_TIMESTAMP 和 TIMESTAMP 列的影响3.1 函数返回值与会话时区的关系MySQL 里 NOW()、CURRENT_TIMESTAMP()、SYSDATE() 等函数返回的是一个“当前时间”但这个当前时间取决于会话时区。内部执行时MySQL 会拿系统 UTC 时间再按会话时区换算成对应窗口时间返回。也就是说同一个时刻你以 08:00 连接NOW() 返回北京时间以 00:00 连接NOW() 返回 UTC 时间。数字上差了 8 小时但代表的是同一时刻。演示一下SET SESSION time_zone 00:00; SELECT NOW(); -- 假设返回: 2025-06-01 06:30:00 SET SESSION time_zone 08:00; SELECT NOW(); -- 同一时刻返回: 2025-06-01 14:30:00这个行为在业务侧很容易造成困惑。如果有一个定时任务用 NOW() 去判断时间窗口而连接时区不一致那么判断逻辑就会产生偏差。更麻烦的是如果代码里依赖 CURRENT_TIMESTAMP 作为默认值写入表中那写入的“墙上时间”也会随着会话时区变化而变化。所以规范连接时区不只是为了查询好看更会直接影响数据落库时的默认值。3.2 DATETIME 和 TIMESTAMP 存储的底层逻辑这是最容易翻车的地方。DATETIME 类型存储的是纯粹的“墙上时间”不包含时区信息。你存什么都不做转换查询出来就是什么。而 TIMESTAMP 类型存储的是 UTC 时间戳从 1970-01-01 00:00:00 UTC 开始的秒数写入时会把会话时区下的时间换算成 UTC 存进去查询时再按当前会话时区换算回来。所以对 TIMESTAMP 而言如果会话时区变了同一行数据的显示值就会变。举例CREATE TABLE t_time ( id INT PRIMARY KEY, dt DATETIME, ts TIMESTAMP ); SET SESSION time_zone 08:00; INSERT INTO t_time VALUES (1, 2025-06-01 12:00:00, 2025-06-01 12:00:00);这时查看数据两边都是 2025-06-01 12:00:00。但把会话时区改为 00:00 再查SET SESSION time_zone 00:00; SELECT * FROM t_time;结果很可能是id dt ts 1 2025-06-01 12:00:00 2025-06-01 04:00:00dt 没变ts 变成了 04:00。原因就是 ts 在写入时把 12:00 理解成东八区换算成 UTC 04:00 存储查询时按 UTC 显示自然就回去了。所以要搞清业务场景如果只是记录业务时间比如下单时间用 DATETIME 加默认值 CURRENT_TIMESTAMP 没问题前提是连接时区稳定如果需要在不同时区下统一展示比如全球访问的社交应用使用 TIMESTAMP 反而更合理因为它在查询时能自动适配会话时区。3.3 时区变化带来的数据“小时数”变化当有人把全局时区从 00:00 改成 08:00已有的 TIMESTAMP 数据在查询时全部会“增加 8 小时”。但 DATETIME 数据不会动。这里要分清TIMESTAMP 底层是时间戳不存在“改坏了”的问题只是展示层换算变化了。DATETIME 则完全是另一回事它存储的是字符串改时区不影响它的值但如果你以为它有 UTC 属性去做计算就可能出错。举个例子你在 UTC 时区下给 DATETIME 存了“2025-06-01 12:00:00”等系统切到东八区这个字段还是显示“2025-06-01 12:00:00”。但实际上你当初想表达的是 UTC 12 点也就相当于东八区 20 点。现在却变成了东八区 12 点时间语义就错了。遇到这类情况别指望靠改时区参数自动转换得用 CONVERT_TZ 函数显式处理UPDATE t_time SET dt CONVERT_TZ(dt, 00:00, 08:00);如果要反过来把 TIMESTAMP 以 UTC 形式导出可以将会话时区设为 00:00 再 SELECT。这种“临时会话切换”不影响其他连接非常适合做数据迁移或跨时区分析。4. JDBC 连接时区参数 serverTimezone 的配合4.1 驱动侧时区与 MySQL 侧时区的双轨制讲了半天 MySQL 内部的 time_zone还有一个容易被忽略的环节应用通过 JDBC 连接 MySQL 时驱动自己也有时区逻辑。MySQL Connector/J 在建立连接时会尝试从服务器读取时区信息然后确定 Java 应用侧应该用什么时区。这个行为受连接串参数 serverTimezone 和 useLegacyDatetimeCode 影响。默认情况下旧版驱动5.x如果检测不到 MySQL 时区会直接用 JVM 默认时区。现在的驱动版本对时区检测更严格如果 MySQL 全局时区是 SYSTEM且系统时区设置得不明确比如缩写为 CST但无法确定地理位置驱动可能直接抛异常提示 “The server time zone value ... is unrecognized”。这个问题在国内太常见了因为很多服务器是 CST但 MySQL 并不知道这个缩写代表的是 China Standard Time 还是 Central Standard Time。解决方法之一就是显式指定 serverTimezoneAsia/Shanghai。4.2 常见的连接字符串配置示例假设应用服务器在北京数据库服务器也在北京业务全部按北京时间展示最简单的连接串可以这样jdbc:mysql://localhost:3306/app_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai或者为了更保险把 MySQL 的全局时区也固定在 08:00此时连接串可以写成jdbc:mysql://localhost:3306/app_db?serverTimezoneGMT%2B8注意 URL 中加号要编码成 %2B否则会被解析成空格。如果服务端和客户端都固定用 UTC连接串就写jdbc:mysql://localhost:3306/app_db?serverTimezoneUTC核心原则是连接串里的 serverTimezone 要和 MySQL 会话时区保持一致或者至少保证含义一致。如果 MySQL 会话时区是 08:00连接串却写 UTC那么驱动在读取时间戳字段时会发生额外的转换最后出现小时偏差。有时候看起来没问题是因为驱动和 JDBC 类型转换逻辑额外做了一次修正但这种“巧合正确”经不起环境变动。4.3 连接参数与时区参数不一致导致的偏差我实际见过一个案例数据库全局时区是 SYSTEM系统时区是 UTC而连接串写的是 serverTimezoneAsia/Shanghai。结果插入 TIMESTAMP 数据时驱动把 Java 里的本地时间当成东八区传给 MySQLMySQL 却按 UTC 来存储最后库里的 TIMESTAMP 内部时间戳比实际少 8 小时。等查询时来看结果会变成比正确时间少 8 小时。另一个案例是数据库配置为 08:00但连接串没写 serverTimezone驱动用了 JVM 默认时区恰好也是东八区这样暂时没问题一旦应用容器迁到别的时区比如部署在国外连接串又没显式指定立刻出现时间错乱。这种问题的排查思路是统一所有环节的时区约定不要依赖系统默认值。可以用如下方式验证连接串实际生效后的 MySQL 会话时区try (Connection conn DriverManager.getConnection(url, user, password); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery(SELECT session.time_zone)) { if (rs.next()) { System.out.println(rs.getString(1)); } }如果输出和你预期不一致优先去查连接串参数和服务端配置。5. 常见问题与排查技巧实录5.1 问题查询结果比实际时间少 8 小时或多 8 小时这种偏差通常只出现在 TIMESTAMP 列或者函数如 NOW() 上。排查第一步先看当前会话时区SELECT session.time_zone;再看系统时区SELECT system_time_zone;如果 session.time_zone 显示 SYSTEM而系统时区又是 UTC那查询结果返回 UTC 时间重叠到北京时间使用就会少 8 小时。解决办法要么执行 SET SESSION time_zone 08:00 验证要么把全局时区和配置文件中 default-time-zone 改为 08:00。对于持续存在的连接池改完需要重启应用或刷新连接池。注意如果你使用的是云数据库服务商提供的 MySQL可能无法直接修改 my.cnf这时候就要在控制台或通过初始化参数设置默认时区具体以服务商文档为准。5.2 问题TIMESTAMP 列的数据在修改时区后错乱例如原本应用以 UTC 写入了一批 TIMESTAMP 数据后来全局时区改成 08:00查询时所有数据都多了 8 小时。这个时候并不需要修正数据因为内部 UTC 时间戳并没有变变了的是展示换算逻辑。如果业务就是想让它按北京时间展示那就应该把应用连接时区切到 08:00如果业务要求固定 UTC 存储和展示就把全局和会话都保留 00:00。但如果仓库里既有 DATETIME 又有 TIMESTAMP你打算把 DATETIME 也视为 UTC那就要小心了。DATETIME 没有隐式转换想把它变成东八区展现只能显式转换SELECT id, CONVERT_TZ(dt, 00:00, 08:00) AS dt_bj FROM t_time;这里要注意 CONVERT_TZ 能否正常工作的前提是时区表已加载或者你只用数字偏移。如果时区表是空的CONVERT_TZ 会返回 NULL。遇到 NULL 的情况检查 mysql.time_zone_name 表是否有数据按前面说的方法加载即可。5.3 问题调用存储过程或触发器时时间不一致存储过程和触发器的执行时间同样基于会话时区。如果应用用 A 时区连接存储过程内部使用了 NOW()返回的时间也是 A 时区下的。如果应用连接串里没指定 serverTimezone而数据库全局时区又乱配就可能导致存储过程里记录时间错位。更诡异的是同一条语句在命令行客户端和业务代码里执行结果不同就是因为两个连接的会话时区不同。排查时把存储过程放一边先验证两个连接的 session.time_zone 是否一致。不一致就统一。推荐在代码启动时主动执行一次 SET time_zone 08:00或者使用连接池初始化查询jdbc:mysql://...?connectionInitSqlsSET%20time_zone%3D%27%2B08%3A00%27这样能强制每个连接启动后都带上正确的会话时区绕过全局默认值的干扰。5.4 排查工具一条 SQL 看全所有时区状态我习惯在任何时区问题排查开始时都跑这几条SELECT global.time_zone, session.time_zone, system_time_zone, NOW(); SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP());TIMEDIFF 可以直接算出当前会话时区相对 UTC 的偏移量非常直观。如果返回 08:00:00说明会话时区是东八区返回 00:00:00说明就是 UTC。这个技巧比查变量更直接因为变量定义是一回事函数计算结果是另一回事两者可能因为各种配置因素产生差异。5.5 常见时区配置速查表写了个简单的对照表方便快速判断自己属于哪种情况场景MySQL 全局时区连接时区连接串 serverTimezone结果预期国内单地部署全部北京时间08:00SESSION 继承为 08:00Asia/Shanghai 或 GMT%2B8一致无偏差国际业务统一 UTC 存储00:00SESSION 继承为 00:00UTC一致无偏差未显式配置依赖 SYSTEMSYSTEM跟随 OSSESSION 继承 SYSTEM不写或自动检测极易受 OS 影响不推荐混合场景统一定为 00:00业务侧手动转换UTC需要应用层自行做展示转换经验是不要用 SYSTEM。它看着省心实际上把服务器操作系统时区这个不可控变量引入了数据库。无论你选 UTC 还是东八区只要写死成具体偏移量或命名时区环境变化时最多需要改一处排查起来要省太多时间。最后再分享一个我自己的习惯建表时如果字段只是记录业务发生时间我会优先用 DATETIME并让它默认值取 CURRENT_TIMESTAMP因为这个值就是你写下的那个时刻的墙上时间与时区换算无关业务记录的语义最直接。像 TIMESTAMP 这种类型更多用在需要全球多时区协同、希望数据库层自动换算的场景。每一次时区问题背后其实都是在问一个问题你这列数据到底代表的是“某个物理时刻”还是“某个时刻的本地表达”想清楚这一点配置 time_zone 就不难了。