MySQL时区实践：时间类型、时区配置与跨时区对账

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

有一次跨区域项目对账，差了一天。金额都对，笔数也对，就是几笔的日期对不上。我先怀疑数据错了，把那一整天的流水翻了个遍。交易记录都在，时间戳也在，没找出毛病。最后才发现，同一笔交易，主库这边看是昨天，报表那边看是今天。

问题不在数据，在时间字段存的是什么。那套系统里，有的表用 TIMESTAMP，有的用 DATETIME。两个类型看着都是时间，底下的存法完全不同。一跨时区，它们就分了叉。我这才明白，时间字段最难的地方不是精度，是先把语义定下来。

差在存储，不在显示

先看它们各自存了什么。TIMESTAMP 存的是一个 UTC 时间戳，4 字节，本质是个整数。DATETIME 存的是打包好的日期时间字面量，5 字节起。这两个是不是一回事，看字节就知道。

SET time_zone = '+08:00';
SELECT ts_col, HEX(ts_col) AS ts_hex, dt_col, HEX(dt_col) AS dt_hex
FROM t_order WHERE id = 1;
-- ts_col: 2026-10-01 08:00:00    ts_hex: 6ABDA280      ← 4 字节
-- dt_col: 2026-10-01 08:00:00    dt_hex: 99BB028000    ← 5 字节

SET time_zone = '+00:00';
SELECT ts_col, HEX(ts_col) AS ts_hex, dt_col, HEX(dt_col) AS dt_hex
FROM t_order WHERE id = 1;
-- ts_col: 2026-10-01 00:00:00    ts_hex: 6ABDA280      ← 显示变了，字节没变
-- dt_col: 2026-10-01 08:00:00    dt_hex: 99BB028000    ← 显示和字节都没变

同一行数据，换个时区再看。TIMESTAMP 的显示变了，可它底下的字节没动。6ABDA280 就是那一刻的 UTC 秒数，0x6ABDA280 = 1790812800。换个会话时区，这 4 个字节还是老样子，变的只是读出来时那道换算。DATETIME 的显示和字节都没动，因为 99BB028000 里压着的，就是你写进去的字面值本身。谁对？看你这个字段想表达什么。记"这一刻发生的事"，TIMESTAMP 更贴。记"单据上写的日期"，DATETIME 更稳。我当时的问题，是两套语义混着用，还指望它们对得上。

（数值按 MySQL 8.0 的时间类型内部格式，换版本以实测为准。）

一个存时刻，一个存日期

除了存法，范围和换算规则也不同。这张表我常放身边，选型时对着看。

最要命的是范围。TIMESTAMP 到 2038 年就到头，对长期数据是硬伤。它对时区的敏感，是优点也是坑。记"哪一刻"，它更准。记"哪一天"，它会把你的日子搅乱。

还有个坑不常被提起。老默认下，表里第一个 TIMESTAMP 列，会被悄悄加上 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。你以为建的是普通时间列，它却在每次更新行时自己改写。MySQL 5.6 起有 explicit_defaults_for_timestamp，打开它这个隐式行为才关掉。建表前先确认这个开关，比事后奇怪"谁改了我的时间"省事。

时区不止一层

时区不是只有一个设置。会话层一个 time_zone，全局层一个，连接层还可能从驱动或参数里再带一个。谁盖住谁，得理清楚。你在客户端改了 time_zone，结果却不合预期，多半是上面一层把它盖了。

SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;

这里有个我踩过的坑。我想用 ‘Asia/Shanghai’ 这种名字，觉得比 +08:00 明白。结果报错，说时区不认识。后来才知道，名字型时区得先把时区表灌进去，不然只能写偏移量。

-- 时区表没灌时，名字型时区会报错
SET time_zone = 'Asia/Shanghai';   -- Unknown or incorrect time zone
-- 退回偏移量能生效，但它丢掉了夏令时规则
SET time_zone = '+08:00';

偏移量能生效，可它只是一个固定差值，碰上夏令时不会替你换算。换个有夏令时的地区，还把 +08:00 写死，切换的那一个小时，TIMESTAMP 存进去的 UTC 时刻就会偏一小时。对账时又对不上。同一笔单子，两边差出一小时，报表按小时聚合时直接错位。

查询和索引，也在这里翻车

时区还藏在查询里。一个看着没问题的按天过滤，结果会漂。

-- 写法一：函数包住字段，索引用不上，还按会话时区取日期
WHERE DATE(ts_col) = '2026-10-01'

-- 写法二：范围条件，索引能用，时区也说得清
WHERE ts_col >= '2026-10-01 00:00:00'
  AND ts_col <  '2026-10-02 00:00:00'

第一种写法叠了两个问题。DATE() 包在字段上，索引直接失效。而且它按当前会话时区取日期，会话时区一变，同一条 SQL 归出来的天就跟着变。对账那天，我以为查询写错了，其实是这两层叠在一起。

差 8 小时，常常是两头都在换算

更常见的来源，在应用和数据库之间。数据库这头按会话时区换算，驱动那头也可能自己再算一遍。两个都算，时间就被平移了两次。我那次就是这样，应用连上来带了一个时区，客户端里设的又是另一个，一叠加，8 小时就出来了。排查时别只盯数据库，先看连接串里带的时区参数。Java 这边常见 serverTimezone、connectionTimeZone。开了 forceConnectionTimeZoneToSession，驱动还会去改写会话时区。对完参数，再看驱动版本怎么处理时间类型。Connector/J 8.0.23 之后，serverTimezone 是 connectionTimeZone 的别名。8.0.22 之前，它覆盖的是服务器时区，不是会话时区。版本不同，同一个参数名的行为可能不同。两头对齐，问题往往就没了。

夏令时那一个小时

时区是暗坑，夏令时是坑里还有坑。有夏令时的地区，切换那天会有一个小时重复，或凭空少掉一个小时。落在这个小时里的本地时间是有歧义的，同一个字符串能对应两个绝对时刻。UTC 存得没问题，可按本地时间归到哪天，规则不写清楚，两个系统就能算出两个日期。要对账，就统一换成 UTC 再比。

迁移和主从，会被它放大

时区的问题，在换库和主从时会放大。存 UTC 的字段，节点挪到别的时区，读出来还是那一刻，对得上。存本地时间字面量的，一旦两端时区设置不一致，同一条记录在两边就是两个值。所以迁移前，我习惯先把时间字段的口径盘一遍，比迁移后救火省事得多。

复制链路上还有一个易漏点。主从用 ROW 格式的 binlog，传的是那个 UTC 秒数，从库按自己的时区换算，只要指向同一时刻就对得上。可要是 STATEMENT 格式，从库重放的是原语句，NOW()、CURRENT_TIMESTAMP 这类会各算各的时区，一路复制下来就能差出小时数。跨时区的主从，binlog 格式和两端 time_zone 最好一起看。

时间字段到底怎么选

踩过这些之后，我的判断是这样。记绝对时刻的，事件、日志、创建时间这类，统一存 UTC，用 TIMESTAMP 或者干脆存时间戳数字。记业务日期的，单据日期、会计日这类，用 DATETIME 存字面值，别让它跟着时区漂。最怕两种混着用，一张表里一个字段想记时刻，一个字段想记日期，边界又不写清楚。对账那天，坑我的就是这种表。

还有两个细节。写当前时间用 UTC_TIMESTAMP()，别用 NOW()，省得依赖会话时区。跨时区对账，先把两边都换成 UTC，再比。

避坑清单

全库时间统一口径。要么都存 UTC，要么都存本地，别混，混了迟早出对账问题。

TIMESTAMP 别当万能。它有 2038 的范围线，还会随会话时区换算。存业务日期就用 DATETIME，存时刻才用它。

还有一条是我自己踩的。我一开始只用偏移量 ‘+08:00’，觉得够用。后来碰上夏令时项目才发现，偏移量不会替我做夏令时换算，得用名字型时区，而名字型时区要先灌时区表。现在接手一套系统，我排查时区先看三件事：连接串带了什么、驱动什么版本、时区表灌没灌。

写在最后

时间字段平时不显眼，出问题就是报表、对账、跨区域协作一起翻车。它难的地方从来不是精度，是语义。你得先说清楚这个字段记的是"哪一刻"还是"哪一天"，再谈怎么存、怎么查。这两个都定了，时区、夏令时、跨区对账才有得聊。

你们系统的时间字段存 UTC 还是本地时间？跨时区对账又是怎么处理的？评论区聊聊。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋