MySQL 会话时区统一与时间字段转换方法

MySQL 时间显示相差 8 小时、同一条记录在不同连接里读出不同结果，通常不是“数据库自动改错了时间”，而是会话时区、字段类型和输入时区没有统一。稳妥的做法是：应用连接建立后显式设置 time_zone，用 TIMESTAMP 保存需要按时区展示的时刻，用 DATETIME 保存不应被自动换算的本地日历值，只有在确实要跨时区转换时才调用 CONVERT_TZ()。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

本文只讨论 MySQL 会话时区统一与时间字段转换，不展开服务器操作系统时区、业务日历规则或夏令时产品设计。

一、目标和边界：先把三件事分开

排查时间问题时，先回答三个问题：当前连接的 @@session.time_zone 是什么；列的类型是 TIMESTAMP 还是 DATETIME；传入的字符串究竟代表 UTC、固定偏移还是某个地区的本地时间。

二、全流程总览：连接、字段、转换、检查点

推荐把流程固定成四层：连接层先设置会话时区；模型层决定字段语义；查询层只在需要展示或迁移时转换；检查层读取当前变量和字段定义。这样可以把“显示偏移”和“保存错误”分开处理。

最小检查语句如下，注释说明每个返回值的排查用途：

-- 查看当前连接采用的会话时区，以及服务器默认时区
SELECT
  @@session.time_zone AS session_tz,
  @@global.time_zone AS global_tz,
  @@system_time_zone AS system_tz;

-- 查看目标表的字段类型，避免把 DATETIME 当成 TIMESTAMP 解读
SHOW CREATE TABLE order_event;

如果不同连接的 session_tz 不一致，先修连接配置；如果字段本身选错，再讨论数据迁移，不能只在查询末尾加一个偏移量。

三、阶段拆解：统一会话时区与转换字段

1. 在连接建立后设置会话时区

单次连接可以使用固定偏移：

-- 用 UTC 作为当前连接的统一口径，避免依赖命名时区表
SET time_zone = '+00:00';

-- 也可以使用已加载到 MySQL 时区表中的地区名
SET time_zone = 'Asia/Shanghai';

固定偏移适合只需要 UTC 或固定偏移的服务；地区名能表达地区规则，但依赖 MySQL 已加载对应时区表。应用使用连接池时，应把这条设置放到连接初始化钩子，而不是只在某个业务请求里执行一次。

2. 根据业务语义选择字段

订单创建、消息发送、审计事件通常是“某个真实时刻”，优先考虑 TIMESTAMP 或统一存储 UTC 的方案；生日、营业时间、门店当地的预约时间更像“日历值”，通常用 DATETIME，并额外保存业务地区。关键不是字段名字，而是写入方和读取方是否约定了同一语义。

3. 需要跨时区展示时再显式转换

-- 把 UTC 的 DATETIME 按命名时区转换为用户看到的当地时间
SELECT CONVERT_TZ(
  event_time,
  'UTC',
  'Asia/Shanghai'
) AS local_event_time
FROM order_event
WHERE event_id = 1001;

-- 参数无效或时区表缺失时，结果可能为 NULL，业务层要保留错误处理
SELECT CONVERT_TZ('2026-11-13 04:00:00', '+00:00', '+08:00') AS converted_time;

转换函数的三个参数依次是原时间、来源时区和目标时区。不要把一个已经按本地时间保存的 DATETIME 再假定为 UTC 转换，否则会产生二次偏移。

四、推荐落地流程：把检查点放在连接生命周期

1. 确定口径：服务间统一约定 UTC，或明确每个服务的会话时区。
2. 检查字段：记录 TIMESTAMP/DATETIME 类型和现有数据的真实含义。
3. 初始化连接：每次新建或重置连接都执行 SET time_zone，不要依赖上一个租户留下的状态。
4. 限定转换：只在报表、接口展示或迁移边界调用 CONVERT_TZ()，存储层不要到处叠加偏移。
5. 保留检查点：问题出现时同时记录 @@session.time_zone、字段类型、原始输入和目标时区。

五、常见误区与速查表

• 只改 global.time_zone：已有连接的 session 值不会因此自动变成你期望的口径，必须检查并设置当前连接。
• 把 DATETIME 当 UTC：DATETIME 没有内置时区语义，来源不清时无法靠查询函数补救。
• 直接给时间加 8 小时：这会绕开地区规则，也无法表达来源和目标时区，优先使用显式转换。
• 忽略命名时区依赖：地区名转换失败时检查 MySQL 时区表是否可用，并处理 NULL。

六、相关问题

MySQL 会话时区应该设置为 UTC 吗？

跨服务协作时通常更容易统一到 UTC，但最终要看系统约定。重要的是连接、字段和接口的口径一致，并且在连接池中可重复执行。

TIMESTAMP 和 DATETIME 能直接互换吗？

不能只改字段类型。迁移前必须确认历史值代表的时区，再决定是否先转换数据；否则字段类型变化可能把原有误解固化。

参考资料：https://dev.mysql.com/doc/refman/8.4/en/time-zone-support.html；https://dev.mysql.com/doc/refman/8.4/en/date-and-time-functions.html