如果你正在被 MySQL 时间时区修改这几个字搞得头大——查出来 time_zone 还是 SYSTEMset global 用完之后隔一阵子又在早晨准时出问题或者改了配置文件 default-time-zone 重启了根本没变化那这篇文章就是给你准备的。MySQL 的时区看起来只是一个小变量实际上牵扯到操作系统时区、全局变量、会话变量、连接层配置还有 mysql 库里那几张不显眼的时区表任何一个环节没对齐“差8小时”就会像牛皮癣一样反复发作。我会把三种修改手段——动态 set global、会话级设置、配置文件 default-time-zone——从原理到操作拆开讲包括踩坑最多的连接池缓存问题争取让你看完就能自己去排。1. 先别急着改搞清楚 MySQL 的时间是怎么“歪”的1.1 三层时区操作系统、全局变量、会话变量很多新手会直接搜“mysql时间时区修改”然后抄一条SET GLOBAL time_zone 08:00就跑了结果经常发现没什么用。问题就出在 MySQL 的时区并不是一层而是三层。第一层是操作系统时区。mysqld 进程在启动的时候会去读系统的时区配置如果 MySQL 参数里没显式指定它就用一个叫SYSTEM的东西兜底表示“我跟随操作系统”。所以你在容器里跑 MySQL宿主机是 UTC容器里也是 UTCMySQL 看到的世界就全是 UTC 时间而你业务方在本地看数据库里的NOW()自然就差了 8 个小时。第二层是 MySQL 全局变量层。MySQL 内部有一个全局变量time_zone它决定所有新建连接默认拿到的会话时区。你可以通过SET GLOBAL在运行时改它也可以通过在配置里写default-time-zone在启动时改它。注意这一层只决定“默认值”不直接强制改掉已经存在的连接。第三层是会话变量层。每一个客户端连接都有自己独立的time_zone会话变量默认继承全局值。你可以针对当前连接单独执行SET time_zone 08:00只影响你自己。这三层关系捋顺了你就能解释很多奇怪现象为什么别人改完立刻好了你改完没反应为什么服务器重启后旧问题又回来了。因为每个人改的根本不是同一层。1.2 从一条 SQL 看时区到底作用于哪里先别急着写配置我建议你先做一次“时区体检”。用一个最土的办法连上 MySQL直接执行下面这条 SQLSELECT global.time_zone AS global_tz, session.time_zone AS session_tz, NOW() AS now_time, UTC_TIMESTAMP() AS utc_time, TIMEDIFF(NOW(), UTC_TIMESTAMP()) AS offset;NOW()返回的是当前会话时区下的时间UTC_TIMESTAMP()返回的是 UTC 时间TIMEDIFF直接算出当前的偏移量。如果offset是08:00:00说明会话时区已经按东八区在走了如果两个时间一模一样说明你还在用 UTC 或者 SYSTEM。这个体检结果很有用。以后排查问题时第一件事不是翻配置而是先跑一遍这条 SQL确认你到底站在哪一层、当前偏移到底是多少。我见过太多人一边嘴上说“我改成东八区了”一边SESSION time_zone还是SYSTEM这不是矛盾是他只改了全局没看自己当前连着的老连接。另外一个容易忽略的点是CURRENT_TIMESTAMP、CURDATE()这类函数都跟着会话时区走UNIX_TIMESTAMP()和FROM_UNIXTIME()在互相转换时也会套用会话时区。也就是说你改了时区不只是表面上多打印 8 小时而是整个时间类型转换链条全部跟着变。2. 临时救急set global 改时区的完整操作2.1 一条命令改全局但别指望它一次生效set global是 MySQL 运行时修改全局变量的标准手段不需要重启服务适合在线上临时改。比如业务方半夜打电话说时间不对你先用一条命令把全局时区拉回来让新连接恢复正常这是最快速的止血方式。命令长这样SET GLOBAL time_zone 08:00;执行完别急着欢呼立刻验证一下。注意这里要用SHOW GLOBAL VARIABLES而不是SELECT session.time_zoneSHOW GLOBAL VARIABLES LIKE time_zone;因为SHOW GLOBAL VARIABLES看的是全局值而session.time_zone看的是当前会话值。很多人就是栽在这一步执行完 set global顺手看session.time_zone发现还是 SYSTEM以为自己没改成功反复执行好几遍其实全局早就改好了。真正的坑在于这个改动只对新建立的连接生效。你自己当前这个命令行连接会话变量还是老样子所以看起来像没生效。想要当前连接也立刻生效可以再补一句SET time_zone 08:00它只影响你当前这个会话。如果线上有连接池里面已经缓存了一堆就连接这些连接不会自动感知全局变化关于这一点我后面专门讲。2.2 权限、报错和验证流程如果你用的是普通账号执行 set global 大概率会遇到权限拦截报错信息一般长这样ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN privilege(s) for this operation在老版本里需要SUPER权限新版本把权限拆得更细需要SYSTEM_VARIABLES_ADMIN之类的动态权限。所以第 1 步是确认账号权限够不够别拿只读账号去操作白折腾。正常的验证流程建议这么走先确认权限再执行 set global再开一个新连接去查或者在当前连接执行SET time_zone 08:00后查。新连接验证才是王道因为线上应用走的是新连接。我习惯在改完之后从另一个终端再连一次 MySQL执行SELECT NOW(), UTC_TIMESTAMP()看看偏移对不对。只有新连接验证通过才敢跟业务方说“止血完成”。2.3 为什么 set global 解决不了长期问题set global 有一个天生的缺陷它只管内存不管磁盘。mysqld 一旦重启全局变量就按启动参数或配置文件重新初始化你 runtime 设的值全部归零又回到 SYSTEM差 8 小时问题准时复发。所以我的判断标准很简单set global 是临时救急不是根治方案。如果只是临时顶一下比如等业务窗口期再重启那没问题。如果指望 set global 一劳永逸那你迟早会在凌晨被报警电话叫醒因为数据库重启或者主从切换之后时区又变回去了。根治还是要落到配置文件上也就是标题里的default-time-zone。3. 重启不失效配置文件 default-time-zone 的正确姿势3.1 配置文件里只改 [mysqld] 这一段配置文件方案的核心是在 MySQL 服务端的配置节里写入default-time-zone。Linux 下一般是my.cnfWindows 下是my.ini具体路径可以通过mysqld --help --verbose | grep defaults-file之类的方式确认。我只说最关键的一定要写在[mysqld]这个段落下面而不是[client]、[mysql]或者文件末尾随便一个地方。正确的写法是[mysqld] default-time-zone 08:00如果你误写成了time_zone 08:00MySQL 在启动时通常会直接忽略或者在错误日志里留下一行看不懂的提示。这块我已经看到不止一个人栽过。写在哪一段、变量名是default-time-zone而不是time_zone这两个细节任何一个错了重启后都是无效变更。修改完配置文件后必须重启 mysqld 才能生效systemctl restart mysqld不同发行版的服务管理命令可能不一样但效果都一样让进程按新配置重新启动。重启完成之后再跑一次第 1 节那条体检 SQL确认global.time_zone变成了08:00。3.2 用偏移量还是用命名时区配置default-time-zone的时候有两种写法一种是我上面写的偏移量写法08:00另一种是命名时区写法例如Asia/Shanghai。两者看起来都能让时间变成东八区但背后的机制完全不同。偏移量写法最省事它不依赖 MySQL 时区表不查任何规则就是硬生生指定 8 小时。中国这边没有夏令时这种概念用偏移量完全够用而且不会引入额外复杂度。命名时区写法更灵活它支持夏令时规则比如某些美洲、欧洲时区一年中不同季节偏移量不一样必须靠命名时区来正确换算。但前提是 MySQL 的 mysql 库里必须已经加载了 IANA 时区数据否则一写Asia/ShanghaiMySQL 直接报错。这个加载动作我下一节专门讲。我个人建议业务不涉及夏令时直接用偏移量。别把简单问题复杂化。你要是写成命名时区还得额外维护时区表而且跨版本升级时表数据可能还要重新处理。3.3 重启验证与存量连接的取舍改完配置文件重启后MySQL 全局变量的默认值会变成你配置的值但这同样只影响新连接。已经存在的连接呢重启都重启了所有旧连接自然都断了连接池里的连接会重连所以重启方案反而比 set global 更彻底——不存在“旧连接还抱着老时区”的问题。但这里有一个必须提醒的运维细节重启 mysqld 不是无痛的它会打断所有正在执行的业务。所以配置文件方案不能随手改随手重启得放在维护窗口期做或者至少确认业务低峰期能容忍一次秒级闪断。如果是云数据库控制台里一般会有参数组修改参数后通常会提示“需要重启实例”效果类似。4. 配了 default-time-zone 还是不生效八成缺了时区表4.1 什么时候会报 Unknown or incorrect time zone如果你在配置里写了default-time-zone Asia/Shanghai重启后 MySQL 直接起不来或者在错误日志里看到类似Unknown or incorrect time zone: Asia/Shanghai这样的信息那八成不是配置语法问题而是 MySQL 的时区表里根本没有这条数据。MySQL 内置了一个叫mysql的系统库里面有五张表和时区相关time_zone、time_zone_name、time_zone_transition、time_zone_transition_type、time_zone_leap_second。这些表平时是空的除非做初始化导入。默认安装的 MySQL 只会认识一个SYSTEM其他时区名一概不认识。所以你配了命名时区就好比你在手机里设置了一个从来没下载过的城市时区系统自然不认。解决办法是把系统的 zoneinfo 数据导入 MySQL。4.2 时区表加载操作与注意事项在 Linux 常见发行版上加载动作一般用一条命令完成mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql它的原理是读取操作系统/usr/share/zoneinfo目录下的时区定义文件转换成 SQL 插入语句再写入 mysql 库的时区表。命令执行完以后不需要重启 mysqld新连接就可以直接使用命名时区了。有几个细节要留意。第一导入必须用有足够权限的账号执行root 是最省事的。第二导入过程中会产生大量 INSERT正常会刷屏这是正常现象。第三如果系统 zoneinfo 目录下存在posix、right这类子目录有些版本的mysql_tzinfo_to_sql要求特殊处理具体看一眼命令的--help输出别把子目录数据导重复了。如果你用的是 Windows 环境的 MySQL通常没有系统的 zoneinfo 文件命名时区导入会比较折腾。这种情况下我强烈建议直接用偏移量08:00绕开时区表依赖省得给自己找事。5. 数据库时区改完了应用还差 8 小时连接层的坑5.1 连接串里的 serverTimezone 才是另一只“程咬金”很多团队踩过一个经典场景MySQL 的时区已经通过配置文件改成08:00了用命令行查NOW()也完全正常但应用打印出来的日志、插入的数据还是差 8 小时。查到最后发现问题出在应用的数据库连接串上。以 Java 的 JDBC 连接为例连接串里可以这样指定时区jdbc:mysql://127.0.0.1:3306/dbname?serverTimezoneAsia/Shanghai如果你的应用服务器自身时区是 UTC但连接串里又没指定 serverTimezone驱动在建立连接时可能会用应用服务器的本地时区去解释数据库返回的时间结果就是数据库存的是对的驱动一层一换算应用里看到又偏了 8 小时。连接层时区和 MySQL 会话时区必须保持逻辑一致要么都是08:00要么都是Asia/Shanghai别一边是东八区、一边是 UTC两层偏移叠在一起神仙都救不回来。新版连接驱动参数更细比如connectionTimeZone、forceConnectionTimeZoneToSession等核心思路没变就是让驱动、会话、应用三个时区对齐。5.2 TIMESTAMP 与 DATETIME 的行为差异时区配置改对了不代表万事大吉还得看业务表里用的是哪种时间字段。DATETIME类型保存的是字面值。你写入2024-01-01 12:00:00读出来就是2024-01-01 12:00:00MySQL 不做任何时区换算纯粹当字符串存。这种类型适合存业务发生时刻比如下单时间展示层的时区问题由应用自行处理。TIMESTAMP类型则完全不同它在存储时会把会话时区下的时间转换成 UTC 再存读取时再转回当前会话时区。所以同一个TIMESTAMP值你换一个会话时区去查查出来的显示结果就不一样。这既是它的灵活性也是它容易让人困惑的地方。比如你的表里有TIMESTAMP字段会话时区从SYSTEM(UTC) 改成08:00历史数据查询结果会整体多 8 小时这不是数据坏了是换算规则变了。排问题时如果发现”时间字段错乱”十有八九就是这个机制在起作用。另外老版本的TIMESTAMP有 2038 年范围限制很多业务为了省心直接用DATETIME。新版本底层时间表示已经往更宽的范围演进但这种历史包袱在存量环境里依然存在选字段类型时别拍脑袋。5.3 连接池缓存会话时区的坑还有一个特别隐蔽的坑连接池。应用启动时连接池会预先创建一批数据库连接每个连接在建立时都会继承当时的全局时区。你后来 set global 改时区或者改配置重启了但应用进程没重启池子里的老连接依然保有旧时区。这时候现象很诡异数据库全局变量是对的新建命令行连接也是对的但应用日志还是错的。因为应用拿的是池子里的旧连接旧连接的会话时区根本没更新。处理办法无非三种重启应用、让连接池重新创建连接比如触发连接回收、或者直接在应用层初始化时显式执行SET time_zone 08:00。第三种方式最稳妥因为它在每次连接建立时都强制执行一次会话时区不依赖全局默认值。很多工业级的连接池初始化脚本里都会带上这条目的就是防“全局改了对不上会话”。6. 实战排查记录与速查表6.1 三个典型的排查实录我先列几个真实环境里反复遇过的场景你看有没有你熟悉的。第一类改了配置不生效。有人在my.cnf里写了default-time-zone但写到了[client]下面重启后SHOW GLOBAL VARIABLES LIKE time_zone还是SYSTEM。这类问题最快定位方法就是检查配置节确认变量名和所在段落。第二类set global 后应用没变化。前面说过连接池缓存了旧连接全局改动对新连接生效但应用还抱着旧连接。这类问题最快验证方法是看应用日志时间如果命令行正确、应用不对那就去查连接池和连接串。第三类数据库、连接串都对但显示还是不对。这个往往出在应用框架本身又套了一层自己的时间格式化工具或者前端展示层做了二次转换。排查到这一步已经跟 MySQL 关系不大了得沿着数据链路往下追别死磕数据库。6.2 五分钟定位时区问题的标准动作我处理任何时区问题时都不直接改配置而是先按顺序执行下面的动作五分钟内就能锁定问题在哪一层先看两层系统变量。SELECT global.time_zone, session.time_zone;再看当前时间和 UTC 的差值。SELECT NOW(), UTC_TIMESTAMP(), TIMEDIFF(NOW(), UTC_TIMESTAMP());然后看错误日志的时间戳配置排除日志误导。SHOW VARIABLES LIKE log_timestamps;接下去检查应用连接串里是否显式指定时区。最后看应用服务器/容器的系统时区。整个过程其实就是把三层时区挨个过一遍哪一层跟预期不一致问题就出在哪一层。6.3 时区修改方案速查表场景推荐方案生效范围重启依赖适合情况临时止血不重启SET GLOBAL time_zone 08:00新连接无线上紧急调整当前会话立刻改SET time_zone 08:00当前连接无自己调试、临时查询长期固定业务无夏令时配置文件写default-time-zone 08:00全局重启保留需要重启生产环境根治长期固定业务跨夏令时配置文件写命名时区 加载时区表全局重启保留需要重启跨国业务应用层兜底连接建立后执行SET time_zone 08:00当前连接无应用连接池环境提示任何修改完成之后都建议再跑一次第 1 节的体检 SQL用NOW()和UTC_TIMESTAMP()的差值验证别只靠猜。我做数据库时间时区调整也已经踩过不少坑后来养成的习惯倒是很简单存储层统一用 UTC展示层由应用按用户本地时区转换数据库的default-time-zone要么不写、要写就写偏移量绝不依赖SYSTEM。这套思路帮我避开了大部分时区问题至少这些坑我不希望你再去趟一遍。