凌晨一点手机连着响了几声群里有人圈我线上订单统计的数据对不上比实际少了一截零点前后的数字明显很奇怪。这种事干后端的基本都经历过。我迷迷糊糊打开终端先干的不是翻代码而是敲了一条几乎变成肌肉记忆的 SQLSELECT system_time_zone, global.time_zone, session.time_zone;。就这一条语句不知道多少个时间差八小时的夜晚要靠它救场。MySQL 的时区问题说难不难说简单又特别容易绕晕。整套体系里有两套时钟、三种设置方式、两类时间字段再加上应用驱动、连接池掺和进来任何一个环节没对齐表现出来都是时间不对。这篇文章我打算把时区相关的变量、设置方式、存储类型一次讲透从原理到实操最后给出一套可以直接抄作业的规范。不管你是刚接触 MySQL 的新人还是被线上时间问题反复折磨过的老手按这个思路捋一遍基本不会再被时区坑到。1. 先搞清楚两套时钟system_time_zone 和 time_zone 谁在管时间1.1 system_time_zone服务器启动时就被焊死的出厂设置system_time_zone是 MySQL 在进程启动的那一刻从操作系统读取的时区值之后全程不变。它是只读的你在会话里执行SET system_time_zone 08:00一定会报错因为没有哪个变量允许运行时改它。它的值完全取决于启动 MySQL 的那台机器的系统时区Linux 上就是/etc/localtime指向的时区容器里则跟随容器环境传入的时区设置。有一个很常见的歧义要提醒这个变量的值经常显示成CST但CST在不同语境下可能是中国标准时间也可能是美国中部时间光看缩写容易误判。靠谱的做法是执行SELECT system_time_zone;拿到结果后再和操作系统date命令的输出对一下两边一致才算确认。大多数情况下我们不需要动它但它有一个关键影响如果全局time_zone保持默认的SYSTEM那么所有新建连接都会拿system_time_zone当作自己的会话时区。换句话说操作系统是东八区MySQL 默认就是东八区操作系统是 UTCMySQL 就默默按 UTC 工作。很多人栽跟头就是栽在服务器装的时候是 UTC业务方却一直按东八区理解这种错位上。1.2 time_zone真正决定你看到几点钟的那个开关time_zone才是日常要关心的变量。它分全局值和会话值默认都是SYSTEM含义是跟随system_time_zone。我们常说的把 MySQL 时区改成东八区改的就是它。它的影响范围比很多人以为的大得多NOW()、CURRENT_TIMESTAMP()、CURDATE()这些函数返回的都是当前会话时区下的时间TIMESTAMP 类型的存储和读取会按会话时区做换算FROM_UNIXTIME()把整数时间戳转成字符串也是按会话时区转的建表时字段的DEFAULT CURRENT_TIMESTAMP默认值同样依赖会话时区。这里的本质是函数返回的永远是一个被解释过的时间解释的规则就是time_zone。同一个数据库A 会话设成08:00B 会话设成00:00两人执行一模一样的SELECT NOW();结果差 8 小时。这不是数据错了是会话时区不同。把这一层想通同事查出来和我查出来不一样的怪事就一点也不怪了。提示判断当前会话到底在什么时区下工作最快的方法是一起执行SELECT NOW(), UTC_TIMESTAMP();。NOW()和UTC_TIMESTAMP()的差值就是当前会话时区偏移。1.3 一个直观实验两个会话的 NOW() 为什么不一样空讲原理不如动手。开两个会话分别设置不同时区-- 会话 A SET time_zone 08:00; SELECT NOW(), UTC_TIMESTAMP(); -- 结果示例2024-11-20 10:00:00 | 2024-11-20 02:00:00 -- 会话 B SET time_zone 00:00; SELECT NOW(), UTC_TIMESTAMP(); -- 结果示例2024-11-20 02:00:00 | 2024-11-20 02:00:00同一时刻两个会话的NOW()差了 8 小时但UTC_TIMESTAMP()完全一致。这说明 MySQL 内部对当前时刻的认知是统一的只是不同会话用了不同的渲染时区。凡是遇到时间对不上的问题先做这个实验基本能定位到是会话时区不一致还是底层数据本身就存错了。2. 时区设置有门道偏移量、命名时区和配置文件的优先级2.1 偏移量格式最朴素也最稳的写法第一种写法是直接给偏移量东八区写成08:00-- 只影响当前会话 SET time_zone 08:00; -- 影响全局新连接默认走这个时区 SET GLOBAL time_zone 08:00;偏移量格式最大的优点是零依赖。它不需要任何外部时区数据文件MySQL 原生就能解析永远不会因为时区表没加载而报错。08:00表示比 UTC 快 8 小时西半球就用负数比如-05:00。运维上想快速让数据库和业务方的东八区认知对齐直接用偏移量是最省事的。缺点也明显偏移量是死的不会跟着夏令时自动跳。如果业务真的处在实施夏令时的时区用偏移量就得人工在换季时改配置容易忘记。对国内大多数业务来说没有夏令时问题08:00就是最靠谱的选择。2.2 命名时区语义清晰但有前提第二种写法是命名时区SET time_zone Asia/Shanghai;这种写法语义化更强MySQL 能据此知道该时区的夏令时规则和历史变更。但前提是 MySQL 已经加载了系统时区表。如果没加载执行会直接报错ERROR 1298 (HY000): Unknown or incorrect time zone: Asia/Shanghai遇到这个报错很多人第一反应是时区名拼错了其实多半是服务器上压根没装时区表。加载方法在第 4 节专门讲。命名时区的好处是规则更新方便——只要系统 zoneinfo 更新MySQL 的规则跟着变坏处是多一层依赖容器环境、云数据库实例里特别容易漏。2.3 全局值和会话值的生效边界会话级别的SET time_zone ...只影响当前连接断开重连就失效全局级别的SET GLOBAL time_zone ...影响的是之后新建的连接不会改动已经存在的连接。这个特性带来一个非常隐蔽的坑你通过某个已建立的连接执行了SET GLOBAL time_zone 08:00以为万事大吉结果应用连接池里那些早就建好的连接仍然保持旧的会话时区。要让它真正生效必须让应用重启或让连接池重建连接。排查我明明改了时区程序还是不对时优先怀疑这一条。注意SET GLOBAL和SET SESSION的生效范围必须分清。改配置文件里的default-time-zone则必须重启实例才生效它不属于运行时热切换手段。2.4 my.cnf 里的一劳永逸方案长期稳定的生产库我推荐直接把时区写进配置文件[mysqld] default-time-zone 08:00改完重启实例global.time_zone就不再是SYSTEM而是08:00。好处是清晰、可审计所有新连接默认就是这个时区不依赖任何会话级设置也不会出现有人偷偷改过的情况。细节上提醒一句配置项别写错分隔符MySQL 的配置项用连字符和下划线通常都能识别但文档里统一写的是default-time-zone我见过因为写成default_time_zone在某些环境下没生效的例子虽然少见但没必要去赌。3. 一切差8小时的源头TIMESTAMP 和 DATETIME 的存储逻辑时区变量只是显示层真正让数据差 8 小时的其实是 TIMESTAMP 和 DATETIME 两种时间类型在存储层的天壤之别。这一节是整个话题的核心值得反复看。3.1 TIMESTAMP把时间换算成 UTC 再存TIMESTAMP 类型的存储逻辑是写入时MySQL 把当前会话时区下的时间换算成 UTC 时间戳再存进去读取时再把 UTC 时间戳换算回当前会话时区下的时间返回。举个例子。会话 A 时区是08:00执行INSERT INTO t(ts) VALUES (2024-11-20 10:00:00);MySQL 把这个值当成东八区的 10 点换算成 UTC 是2024-11-20 02:00:00存进去的是这个 UTC 时刻。之后会话 B 时区是00:00执行SELECT ts FROM t;MySQL 把 UTC 的02:00:00换算成会话 B 的本地时间返回2024-11-20 02:00:00。同一个物理时刻A 看到 10 点B 看到 2 点。数据本身没变变的是渲染时区。这就是 TIMESTAMP 的时间点语义——它永远表示一个绝对时刻跟你在哪个时区看它无关只要各会话时区配置正确谁读都是对的。3.2 DATETIME墙钟时间原样保存不做任何换算DATETIME 完全不同。它不参与任何时区换算2024-11-20 10:00:00写进去不管会话时区怎么改读出来永远是2024-11-20 10:00:00。它只有墙上时钟的语义没有绝对时刻的概念。这带来的后果是反直觉的如果一个 DATETIME 字段的值在东八区写入10:00换到 UTC 会话去读出来的还是10:00但这个10:00代表的绝对时刻已经和写入时的10:00完全不是一回事了。换句话说DATETIME 的含义完全取决于业务方约定用什么时区解释它而数据库本身不记录、不校验、不转换。两类字段还有一个经典差异TIMESTAMP 的范围只有 1970 到 2038 年DATETIME 的范围是 1000 到 9999 年。存生日、历史纪事这类日期用 DATETIME 才现实。3.3 选型原则和一张对比表我在实际项目里的取舍原则很简单凡是表达这一刻发生了什么的事件时间——订单创建时间、日志产生时间、操作记录时间——用 TIMESTAMP。因为它表达绝对时刻业务方不管在哪个时区只要会话时区配置正确读出来的就是本地时间天然安全。凡是表达某种约定下的日期——出生日期、排期日期、账单周期——用 DATETIME。这类数据本质是日历上的某一天不应随观察者时区变化。对比维度TIMESTAMPDATETIME存储基准UTC 时间戳原样保存墙钟时间时区转换写入、读取都按会话时区换算完全不换算时间范围1970 ~ 2038 年1000 ~ 9999 年存储占用更紧凑相对更宽适合场景事件发生时刻日历日期、约定时间如果项目里统一约定所有时间都按东八区理解、爱咋存咋存那 DATETIME 也能凑合。但一旦业务跨时区或者服务器部署在 UTC 环境TIMESTAMP 的优势会彻底体现不需要在每个查询里手动加偏移只要会话时区统一时间自然正确。4. 命名时区加载失败mysql_tzinfo_to_sql 的完整操作前面提到SET time_zone Asia/Shanghai需要时区表。这一节把加载过程完整走一遍顺便说清验证方式。4.1 先确认到底缺不缺时区表执行下面这句如果结果为空说明时区表没有加载SELECT * FROM mysql.time_zone_name WHERE Name Asia/Shanghai;MySQL 的时区表在mysql库下核心是time_zone和time_zone_transition等表time_zone_name是便于查询的入口。默认情况下这些表是空的需要手动灌数据。很多新装的数据库、精简容器镜像都没有这一层数据。4.2 从系统 zoneinfo 导入大多数 Linux 发行版都带/usr/share/zoneinfo目录里面是标准的 tzdata 时区文件。用 MySQL 自带的工具导入mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql这个命令会把系统里的所有时区规则转换成 SQL 语句写入mysql库。如果系统没有/usr/share/zoneinfo比如某些精简容器镜像先装 tzdata 包或者从同版本的其他机器拷贝一份。执行完再验证一下SELECT COUNT(*) FROM mysql.time_zone_name;正常情况会有几百条记录Asia/Shanghai一定在里面。这时再执行SET time_zone Asia/Shanghai;就不会报错了。4.3 加载时区表之后的隐藏问题导入过程有几点要留意。第一mysql_tzinfo_to_sql生成的语句量不小在比较老的版本上可能耗时偏长耐心等别中途断掉。第二如果用了主从复制时区表的变更会通过 binlog 同步检查的时候主库从库都要看一遍。第三有些云数据库实例不允许你直接写mysql库那就只能用偏移量格式——这也是我说偏移量最稳的现实原因之一。还有一点容易忽略加载完时区表并不代表现有连接的时区会自动变成命名时区。你仍然需要SET GLOBAL time_zone Asia/Shanghai;或改配置文件后重启新连接才会生效。顺序搞反的话会误以为加载失败了。5. 实战排查实录一个典型的时间对不上案例理论说再多不如把一次真实排查过程拆开看。以下是之前处理过的一个问题现象、排查链路和最终根因都很典型值得收藏。5.1 现象库里的时间看起来没事某业务系统上线后运营反馈后台统计的订单数据对不上而且每天零点前后的数据明显异常。开发同学查了数据库发现订单表的create_time字段是 DATETIME 类型值本身看着都是对的比如2024-06-01 10:00:00这种格式。但程序里另一个索引中的时间字段却比数据库早 8 小时两边怎么都对不上。第一反应都是数据库时区错了。我先让现场执行了三句话SELECT system_time_zone; SELECT global.time_zone, session.time_zone; SELECT NOW(), UTC_TIMESTAMP();结果很清晰system_time_zone是UTCglobal.time_zone是SYSTEMsession.time_zone也是SYSTEM而NOW()和UTC_TIMESTAMP()完全相等——也就是说 MySQL 服务器整体跑在 UTC 上但业务方一直按东八区理解所有时间。5.2 排查链路从三行 SQL 到连接串这还没完真正的根源在应用连接层。应用连接 MySQL 的连接串里没有显式指定时区参数驱动在握手时读到的服务器时区是UTC于是它把数据库返回的时间字符串按 UTC 解释再转成应用服务器的本地时区东八区渲染时间就凭空多了 8 小时。而那张 DATETIME 字段里的create_time其实是应用层用本地时间生成的字符串直接写进去的。写入时不经过 MySQL 时区换算读出来自然还是那个字符串所以看着对。一个是按 UTC 解释后又转了 8 小时的一个是原封不动的墙钟时间对不上是必然结果。5.3 修复和复盘修复分两步先把数据库全局时区改成08:00同时把应用连接串里加上serverTimezoneAsia/Shanghai然后让连接池重建连接。改完后NOW()、驱动读取、下游索引三方对齐数据恢复一致。这次排查教会我的三件事第一出问题时不要只盯数据库要盯整条链路上的所有环节——MySQL 会话时区、连接驱动时区、应用服务器系统时区、下游存储时区哪一环不一致都会在某一层体现出来。第二DATETIME 字段看着正常不代表没问题它只是墙钟时间一旦某个环节按另一种时区解释它立刻出岔子。第三连接池里的旧连接会继续用旧时区改完必须处理连接重建否则验证起来会被看起来没生效反复误导。6. 生产环境时区规范我的推荐配置清单6.1 推荐的基线配置组合我推荐的基准配置是操作系统、MySQL、应用容器、时区数据全部统一到同一套时区语义。具体做法如下服务器操作系统要么全 UTC要么全东八区不要混合。容器部署注意容器内的/etc/localtime和宿主机是否一致。MySQL配置文件里写default-time-zone 08:00不依赖SYSTEM的隐式继承。应用层连接串显式传时区参数比如 Java 侧就是serverTimezoneAsia/Shanghai。代码规范写入时间尽量统一用 UTC 生成展示时再转本地时区避免各模块各自为政。这套组合的好处是即使某个环节被改乱排查时也有明确的对照基线而不是对着一堆默认值猜。6.2 连接池与中间件的时区联动连接池连接在建立时拿到的是当时的会话时区之后SET GLOBAL修改不会回灌到这些连接上。如果必须在线切换时区建议先SET GLOBAL然后让应用重启或触发连接池的连接失效重建。很多连接池支持配置初始化 SQL比如每次拿到连接先执行SET time_zone 08:00这是一种保险做法能防止有些连接被人改过、还回来时带了一身奇怪时区的问题。数据库中间件和代理层也要留意这类组件自己也有时区参数。数据库时区改了代理层没改照样出问题。每次排查时间问题时把代理层加进检查清单能省很多来回。6.3 几个容易被忽略的角落最后说几个实际踩过的细节FROM_UNIXTIME()和UNIX_TIMESTAMP()的行为依赖会话时区。同样一条 SQLtime_zone不同结果不同做报表统计的人最容易中招。使用DEFAULT CURRENT_TIMESTAMP的表中如果写库连接的时区和读库连接的时区不一致读出来的默认值会给人造成数据凭空变了的错觉。跨时区团队的协作规范比技术配置更重要。见过一个项目里一半表用 DATETIME、一半用 TIMESTAMP开发约定也没有全靠案例式排查救火。建议在数据库设计文档里明确规定事件时间用 TIMESTAMP日历日期用 DATETIME会话时区固定为08:00任何模块不得私自改动。我在实际项目里最后形成的习惯是所有服务的连接串统一维护在一份配置模板里时区参数作为必填项数据库上线检查清单里永远有SELECT global.time_zone, session.time_zone;这一项凌晨被叫起来处理时间差八小时的次数从那之后几乎降到了零。时区这事本身不复杂复杂的是链路上每个人都默认别人和自己想的一样。把这层默认显式化问题就从源头消失了。