MySQL time_zone参数详解：时区配置不当引发的生产事故

1. 时区参数到底管什么：先搞明白它为什么值得单独写一篇

MySQL 的time_zone，乍一看就是个"设置时间地区"的小参数，很多 DBA 和开发同学可能直到线上出问题才意识到它的分量。我见过不少生产事故——有的是存储的时间对不上，有的是定时任务提前或延后一小时执行，还有的是主从复制后数据时间戳错乱，追根溯源，几乎都指向这个参数没配置对。

先说这个参数的本质：它决定了 MySQL 服务器在解析和存储时间相关数据时，采用哪个时区作为基准。它不光影响NOW()、CURDATE()、CURRENT_TIMESTAMP这类函数的返回值，还会影响TIMESTAMP类型字段的存储和读取逻辑，甚至连日志里的时间戳、SHOW PROCESSLIST里显示的时间，都会跟着它走。

time_zone参数分为全局级别（GLOBAL）和会话级别（SESSION）。全局级别通过SET GLOBAL time_zone = '...'设置，会作用于之后新建立的连接；会话级别通过SET time_zone = '...'设置，只影响当前连接。这里有个细节很多人忽略：全局设置不会影响已经存在的连接，所以你改了my.cnf后如果没重启，旧连接还是旧时区，新连接才会生效。

它的合法取值有三类：

• 系统默认值SYSTEM，表示跟随 MySQL 所在操作系统的时区设置；
• 偏移量形式，比如'+08:00'、'-05:30'；
• 命名时区，比如'Asia/Shanghai'、'UTC'，但前提是 MySQL 已经加载了系统时区表。

很多生产环境安装 MySQL 时根本没管过这个参数，用的就是默认的SYSTEM。这在一台时区本来就配置正确的服务器上通常没事，但一旦服务器时区被改、或者迁移到云上默认 UTC 的机器，问题就接踵而至了。

这篇文章适合谁看？只要是跟 MySQL 打交道的人——DBA、后端开发、运维、数据分析师——都建议花十分钟过一遍。它解决的是最让人头疼的"时间对不上"问题，同时也会帮你避开几个我在实际环境中踩过的坑。

2. SYSTEM 这个大坑：服务器时区一变，数据库时间就全乱了

2.1 SYSTEM 的真实行为：不是在读取，而是在"跟随"

默认情况下，time_zone的值是SYSTEM，意思是 MySQL 直接使用操作系统当前的时区设置。你可能会觉得，"跟随系统"没什么不好，反正服务器时间准就行。但问题恰恰出在这个"跟随"上。

MySQL 在每次处理时间相关操作时，都会去调用操作系统的本地时间接口。也就是说，如果你改了操作系统的时区（比如从Asia/Shanghai改成UTC），MySQL 的NOW()返回值会立刻变化，已经存进TIMESTAMP字段的数据在读取时也会跟着发生偏移。

举个我实际遇到过的例子：某台线上数据库服务器，原来系统时区是CST（中国标准时间，即 UTC+8），time_zone保持默认SYSTEM，一切正常。后来机房维护时，运维同学出于"统一规范"的考虑，把系统时区改成了UTC，结果第二天业务方就报"订单时间全部慢了 8 小时"。查下来的原因很简单——系统时区变了，MySQL 的SYSTEM时区也跟着变了，所有TIMESTAMP字段的展示值全部偏移。

更隐蔽的问题是：这种问题往往不是立刻暴露的。如果改完系统时区后，有新的数据写入，新数据和旧数据之间会出现 8 小时的"断层"；如果业务数据量不大、流量不高，你可能好几天都发现不了，直到对账或者报表统计时才觉得不对劲。

2.2 TIMESTAMP 与 DATETIME 的存储差异：一个存 UTC，一个存字面值

要彻底理解time_zone的影响范围，必须搞清楚 MySQL 两种时间类型的底层存储逻辑。

TIMESTAMP类型：内部存储的是 UTC 时间戳，从1970-01-01 00:00:00到2038-01-01 19:14:07。写入时，MySQL 会把会话时区下的时间转换成 UTC 时间戳存进去；读取时，再把 UTC 时间戳转换成当前会话时区下的时间显示出来。所以，当会话的time_zone改变时，同一个TIMESTAMP字段的显示值也会跟着变。

DATETIME类型：存储的就是字面值，'2024-01-15 10:00:00'存进去就是'2024-01-15 10:00:00'，不做任何时区转换。它不受time_zone影响，无论会话时区怎么改，读出来的都是当初存进去的那个字面值。

这就带来一个非常经典的坑：很多开发在建模时不愿意用TIMESTAMP，因为 2038 年问题，转头全用DATETIME。DATETIME本身没有问题，但如果应用层连接串里的时区参数配置不一致，或者服务器时区变了，DATETIME存进去的"字面值"就可能是错的——因为应用生成这个字面值时，用的可能是它自己的本地时间。

建议是：两者都行，但必须明确语义。如果存的是"某个时间点的绝对时刻"（比如订单创建时间），用TIMESTAMP更合适，因为它在读取时能按会话时区正确换算；如果存的是"日历上的某个时间"（比如排课表上的上课时间），用DATETIME更合适，因为不应该随着时区变化而漂移。最忌讳的是混用且不约定清晰，到时候排查问题会非常痛苦。

2.3 命名时区加载问题：为什么 'Asia/Shanghai' 会报错

time_zone除了支持SYSTEM和偏移量，还可以设置为命名时区，比如'Asia/Shanghai'。但很多人在my.cnf里写上default-time-zone = 'Asia/Shanghai'，重启 MySQL 后却直接报错，错误信息类似Unknown or incorrect time zone: 'Asia/Shanghai'。

原因很简单：MySQL 默认没有加载操作系统时区表到自己的mysql.time_zone_name表中。需要用mysql_tzinfo_to_sql工具来导入，命令大致如下：

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

导入完成后，还需要验证一下：

SELECT * FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai';

如果能看到记录，说明导入成功，此时再设置default-time-zone = 'Asia/Shanghai'就不会报错了。

不过，运行过线上 MySQL 的人应该都有感受：大多数人不会走"命名时区"这条路，因为多了一步导入操作，而且一旦服务器迁移，时区表需要重新处理。更常见的做法是直接写偏移量，比如'+08:00'。偏移量的好处是简单、直接、不依赖系统时区表，坏处是夏令时问题无法处理，但国内不存在夏令时，所以 +08:00 完全够用。

注意：如果你的业务涉及多个时区的用户（比如跨境电商），偏移量方式就不够灵活了。此时命名时区配合会话级time_zone设置才是正解——不同用户连接后设置不同的会话时区，读写时间各自换算。

3. 连接层与部署场景：真正让你踩坑的往往在 MySQL 之外

3.1 JDBC 连接串中的 serverTimezone 参数

后端开发最常见的时区问题，其实不在 MySQL 服务端，而在 JDBC 连接串上。很多 Java 项目报错The server time zone value 'CST' is unrecognized，原因就是连接串里没有明确指定时区，而 MySQL 服务端返回的时区信息是CST这种缩写，JDBC 驱动解析不了。

正常做法是在 JDBC 连接串中显式加上serverTimezone=Asia/Shanghai或serverTimezone=GMT%2B8（注意 + 号要编码成 %2B）。比如：

jdbc:mysql://localhost:3306/mydb?useSSL=false&serverTimezone=Asia/Shanghai

但这里有另一个容易被忽略的细节：JDBC 连接串里的serverTimezone必须与 MySQL 服务端实际的time_zone一致，否则会出现"写入时套了一层转换，读取时又套了一层转换"的双重换算问题。

我举个实际场景：MySQL 服务端time_zone是SYSTEM，而服务器系统时区是 UTC；Java 应用跑在另一台时区为 UTC+8 的机器上，JDBC 连接串写的是serverTimezone=Asia/Shanghai。此时 JDBC 驱动认为 MySQL 服务端是东八区，就把应用的时间转成 UTC 后发过去；MySQL 收到后又按自己的 SYSTEM（UTC）解析。来回一折腾，你以为存的是北京时间，库里实际存的是偏差了几个小时的值。

总结成一条经验：服务端配置、JDBC 连接串、应用服务器时区三者必须统一。最省事的方案是，MySQL 服务端显式设置time_zone = '+08:00'，JDBC 连接串写serverTimezone=Asia/Shanghai，应用服务器系统时区也设为Asia/Shanghai，三边对齐，永绝后患。

3.2 连接池里的会话时区污染问题

连接池是另一个常见的"时区污染源"。比如 HikariCP、Druid 这类连接池，连接复用是基本操作。如果一个连接曾经被某个会话设置过SET time_zone = '+00:00'，归还到连接池后，下一个从池里拿到这条连接的会话，会继续沿用这个时区设置。

这就可能导致一个诡异的现象：同一个应用，有时查询出来的时间是对的，有时是错的；或者不同接口返回的时间不一致。原因就是连接池里的连接带着不同的会话时区状态。

解决办法有几个方向：

• 在应用启动后的初始化 SQL 中统一执行SET time_zone = '+08:00'，HikariCP 的connectionInitSql参数正好干这个事；
• 在获取连接后、执行业务 SQL 前，由 ORM 框架统一设置时区；
• 最彻底的办法，在 MySQL 服务端把全局time_zone写死成目标时区，同时要求应用侧禁止任何形式的会话级time_zone修改。

从实际运维角度推荐第三种：全局写死 + 禁止应用改会话时区。原因很简单——人是不可靠的，少一个变量就少一类故障。如果确实有业务需要不同时区，也建议用独立的账号或独立的实例来隔离，而不是在同一套环境里反复横跳。

3.3 Docker 与 Kubernetes 部署：进去就是 UTC

现在不少团队把 MySQL 跑在 Docker 容器里，而官方 MySQL 镜像的基础系统时区默认是 UTC。如果你用docker run启动 MySQL，不额外配置时区，容器的系统时区就是 UTC，而 MySQL 的time_zone默认SYSTEM，最终效果就是：MySQL 的所有时间函数都按 UTC 走。

如果你宿主机是东八区，业务代码也认为时间应该走东八区，那写入的时间就会差 8 小时。这个坑在测试环境经常出现——本地开发用本机装的 MySQL 没问题，一上容器化测试环境就出现时间错乱。

解决方式有两种：

第一种，启动容器时挂载时区文件：

docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -e TZ=Asia/Shanghai \ mysql:8.0

第二种，在 MySQL 配置中直接指定：

[mysqld] default-time-zone = '+08:00'

我倾向于两种都做。挂载localtime保证操作系统层面是东八区，default-time-zone = '+08:00'保证 MySQL 不依赖系统时区——双保险，避免将来有人调整容器时区时把数据库也带偏。

Kubernetes 部署时同理，Pod 的spec.containers.env里加TZ=Asia/Shanghai，或者直接用timeZone字段（K8s 1.27+ 支持），但最稳的还是在 MySQL 配置里写死default-time-zone。

3.4 主从复制架构中的时区一致性

主从复制下，time_zone的影响更隐蔽。MySQL 主从复制传播的是 binlog 中的事件。对于TIMESTAMP类型，binlog 里记录的是 UTC 值，备库重放时会按照备库的time_zone转换成当地时间。这意味着：主库和备库的time_zone不一致时，备库上的TIMESTAMP字段值会和主库不一致。

我已经见过不止一次这样的案例：主库时区是 +08:00，从库时区是 SYSTEM 且系统是 UTC。主从同步后，从库的数据看起来全都"慢了 8 小时"。由于很多监控和报表查询走的是从库，这个问题会绕一大圈才被发现。

解决方案也很直接：主从环境的所有节点，time_zone必须保持一致。最严谨的做法是主从都显式配置default-time-zone = '+08:00'，不要依赖系统时区。

顺便提一个跟热词"使用 Flink 实现 MySQL 同步到 ClickHouse"相关的点：Flink CDC 在读取 MySQL binlog 时，会把时间字段转换成字符串。如果 MySQL 的时区设置不一致，同步到 ClickHouse 的时间数据也会跟着错。你在 Flink CDC 的配置里通常会看到debezium.time.precision.mode之类的参数，但很少有人意识到，源端 MySQL 的time_zone才是这一切的起点。

4. 函数行为与 SQL 性能：time_zone 比你想的更影响"查询结果"

4.1 NOW() 与 CURRENT_TIMESTAMP 的会话级差异

NOW()、CURRENT_TIMESTAMP、CURRENT_TIMESTAMP()这几个函数返回的都是"当前会话时区下的时间"。它们的值不取决于你调用时的参数，而是取决于当前会话的time_zone。

举个容易迷惑的案例：你在一个会话里执行：

SET time_zone = '+00:00'; SELECT NOW();

输出可能是2025-01-16 02:30:00。紧接着执行：

SET time_zone = '+08:00'; SELECT NOW();

输出就变成了2025-01-16 10:30:00。

同一个时刻，两个不同的返回值。如果应用代码里先执行了某个设置会话时区的逻辑，再调用NOW()来生成"业务时间"，那你生成的时间就跟实际业务时区对不上了。

很多 ORM 框架（比如 MyBatis）支持在 mapper XML 里直接写数据库函数，比如NOW()作为插入时间。如果应用的连接时区和业务期望时区不一致，这个NOW()生成的时间就会偏。我个人更推荐在应用层生成时间，而不是依赖数据库的NOW()——一方面便于统一控制，另一方面也方便将来做单元测试时 mock 掉当前时间。

4.2 TIMESTAMP 字段上的索引与隐式转换

TIMESTAMP字段的查询有一个隐式转换的坑。假设你有一个订单表，下单时间字段create_time是TIMESTAMP，业务查询条件是：

SELECT * FROM orders WHERE create_time >= '2025-01-01 00:00:00';

这里的字符串'2025-01-01 00:00:00'会被 MySQL 按当前会话时区解释，然后换算成 UTC 时间去和存储的 UTC 值比较。如果会话时区变了，同一个 SQL 的查询范围就变了，查出来的数据行数也会不同。

这在"一次 8 小时时区切换事故"中表现得很明显：业务方在白天 10 点查"今天 0 点至今的订单"，如果会话时区被错误地设置成了 UTC，那 0 点对应的 UTC 时间会被换算成北京时间的 8 点，于是 8 点之前下的单全被漏掉了。

更麻烦的是，如果 SQL 里对TIMESTAMP字段使用了函数，比如DATE_FORMAT(create_time, '%Y-%m-%d')，那索引就直接失效了。MySQL 会对索引列做隐式转换或函数计算，导致无法走索引，全表扫描。这跟我们开头热词里的"mysql 排序""mysql 锁的分类"没直接关系，但在排查慢查询时经常碰得到。

建议：范围查询尽量用原始字段直接比较，不要包函数；如果要按天分组或格式化，可以考虑加一个DATETIME冗余列或者生成列，预先算好，再在生成列上建索引。

4.3 time_zone 对 Performance Schema 和日志时间戳的影响

还有一个常被忽略的角落：MySQL 的慢查询日志、错误日志、SHOW PROCESSLIST和 Performance Schema 表中记录的时间戳，使用的都是会话或全局的time_zone设置。

假设一个场景：DBA 在看慢查询日志，发现某个 SQL 执行时间是2025-01-16 03:00:00，而应用监控显示这个 SQL 在2025-01-16 11:00:00被调用。两边对不上，排查了半天，最后发现是慢查询日志的时间基于是 UTC（因为 MySQLtime_zone是 SYSTEM 且系统是 UTC），而业务监控是基于北京时间。时间一差，整个排查链路就乱了。

所以我在规范 MySQL 配置时会强制加上一条：慢查询日志和错误日志里能明确看出时区。如果用的是默认SYSTEM，至少确保系统时区是Asia/Shanghai或UTC，并且团队内所有人都知道这个基准。最省心的做法依然是显式default-time-zone = '+08:00'，一天 24 小时，哪个日志都一目了然。

4.4 性能影响：SYSTEM 时区为什么慢一点

这一点知道的人不多，但值得展开说说。MySQL 官方文档里有一条提示：如果time_zone设置为SYSTEM，每次调用时间函数时，MySQL 都要读取操作系统时区，这会有一次额外的函数调用开销。

单独看一次调用的开销微乎其微，但在高并发场景下，如果某个 SQL 频繁调用NOW()、CURRENT_TIMESTAMP，或者大量写入使用TIMESTAMP DEFAULT CURRENT_TIMESTAMP，累积起来的开销就不容忽视了。

Percona 曾经做过测试，在高并发只读场景下，time_zone从SYSTEM改成固定偏移量后，整体吞吐有可感知的提升。如果你的数据库写入量大，或者对延迟敏感，建议把time_zone设置成固定值，抛开SYSTEM。

把default-time-zone = '+08:00'写进my.cnf，或者在启动参数里加--default-time-zone='+08:00'，既解决了正确性问题，又顺带减少了时间函数调用的开销，属于低成本高收益的操作。

4.5 一个被忽略的冷知识：TIMESTAMP 的范围也受 time_zone 影响

TIMESTAMP类型的取值范围是1970-01-01 00:00:01UTC 到2038-01-19 03:14:07UTC。但注意，这是 UTC 范围。如果你把会话时区设置成+08:00，那么你能写入的"本地时间"范围就变成了1970-01-01 08:00:01到2038-01-19 11:14:07。

也就是说，理论上你可以写入一个本地时间为1970-01-01 03:00:00的值（它在 +08:00 时区下对应的是 UTC 的1969-12-31 19:00:00），但这个值实际上超出了TIMESTAMP的存储范围，MySQL 会报错或者返回 NULL。

这种极端边界情况虽然在业务中不常见，但如果你要处理历史数据补录、数据迁移之类的工作，就可能会碰到。数据迁移时源库时区设置和目标库时区设置如果不同，时间字段极易出现溢出或错位。这也是为什么我在做数据迁移项目时，第一步永远是确认两端 MySQL 的time_zone是否一致。

5. 常见问题排查与避坑实录：这些坑我替你踩过了

5.1 经典案例一：CST 到底代表哪个时区

CST这个缩写非常坑人——它可以同时代表四个时区：

• China Standard Time（UTC+8）
• Central Standard Time（美国中部标准时间，UTC-6）
• Cuba Standard Time（古巴标准时间，UTC-4）
• Central Standard Time（澳洲中部标准时间，UTC+9:30）

MySQL 在某些版本或某些系统上，SHOW VARIABLES LIKE 'time_zone'会返回CST。问题是，这个CST到底指哪个时区，取决于操作系统和 MySQL 的解析规则。在中国服务器上通常被解析为东八区，但在某些云厂商的默认镜像里，CST可能被解析成美国中部时间，一差就是 14 个小时。

所以我的建议很明确：永远不要在你的日志、配置、连接串里使用CST这种缩写。要用就用+08:00这种明确偏移量，或者Asia/Shanghai这种 IANA 时区名。一次配置到位，省得后面反复踩坑。

5.2 经典案例二：为什么TIMESTAMP存进去和查出来不一样

有同学遇到过这种问题：应用插入了一条数据，create_time传的是'2025-01-16 10:00:00'，在数据库里执行SELECT查出来却是'2025-01-16 02:00:00'。

发生这个问题的原因大概率是：应用连接数据库时，JDBC 连接串或 ORM 配置里有一个时区，而 MySQL 的全局time_zone是另一个时区。应用认为自己在存"北京时间 10 点"，MySQL 却把它按"UTC 时间"理解，存进去的是 UTC 时间戳02:00:00，读取时又按 UTC 显示，于是你就看到了02:00:00。

排查思路：先看全局和会话时区：

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

再看系统时区：

timedatectl

最后看应用连接串和 ORM 配置。一层层排查，通常很快就能锁定是哪一边出了问题。

5.3 经典案例三：定时任务为什么总在奇怪的时间点执行

如果业务里用到了 MySQL 的EVENT（事件调度器），你可能也会遇到定时任务时间不对的问题。EVENT的执行时间是基于time_zone的。如果time_zone被调整，已创建的事件执行时间会跟着变化。

举个例子：你创建了一个每天凌晨 2 点执行的事件，用的是EVERY 1 DAY STARTS '2025-01-16 02:00:00'。如果time_zone从+08:00改成了+00:00，那么这个事件的执行时间就变成了 UTC 的凌晨 2 点，对应北京时间上午 10 点。一个原本应该在业务低谷执行的清理任务，突然跑到了业务高峰时段，完全有可能拖垮数据库性能。

排查时可以用：

SELECT EVENT_NAME, STARTS, TIME_ZONE FROM information_schema.EVENTS;

来查看事件定义时的时区上下文。如果发现异常，建议重建该事件，并在事件定义时用TIMESTAMP类型的字面值配合CONVERT_TZ函数来确保行为一致。

5.4 经典案例四：连接池中偶发的时间错乱

前面提过连接池会话时区污染。这个问题排查起来格外痛苦，因为它不是必现的——只有当你从池子里拿到的恰好是那条"被污染"的连接时，问题才出现。

有一次我排查一个"10% 概率时间错乱"的问题，怀疑过缓存、怀疑过应用代码的并发问题，最后才想到连接池。通过在连接池初始化 SQL 里加了SET time_zone = '+08:00'后，问题立刻消失。后来我在框架层约定：连接池必须配置连接初始化 SQL，补齐时区设置。HikariCP 的配置类似：

spring: datasource: hikari: connection-init-sql: SET time_zone = '+08:00'

Druid 也有类似的connectionInitSqls配置。不管用哪个连接池，这个初始化步骤强烈建议加上，尤其是你的应用可能会被多个团队复用、配置不可控的情况下。

5.5 快速排查清单：MySQL 时间问题的一站式检查

把上面这些经验收敛成一张排查清单，遇到时间问题从上到下过一遍，基本可以覆盖 90% 的场景：

这套清单我在好几个项目里都用过，基本可以做到"十分钟定位问题"。

6. 最佳实践与配置建议：一次配好，永不再烦

6.1 生产环境推荐的配置方案

结合实战经验，我给出一套适用于绝大多数国内业务团队的生产配置方案：

MySQL 配置文件/etc/my.cnf中：

[mysqld] default-time-zone = '+08:00'

如果使用命名时区（适合多时区业务）：

[mysqld] default-time-zone = 'Asia/Shanghai'

但记得先执行：

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

应用层 JDBC 连接串：

jdbc:mysql://host:3306/db?useSSL=false&serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false

其中useLegacyDatetimeCode=false也很关键，它让 JDBC 驱动完全使用serverTimezone参数来解析时间，而不去读 JVM 默认时区。

连接池配置连接初始化 SQL：

SET time_zone = '+08:00';

我在实际环境中还会顺手做两件事：

一是检查并记录所有数据库实例当前的time_zone值，纳入监控体系，变成巡检项之一；

二是在发布文档里明确写：除非业务特殊需求，禁止在代码里执行SET time_zone语句。任何需要改时区的需求，先走变更评审。

6.2 多时区业务场景的应对思路

如果你的业务确实覆盖多个时区（比如跨境电商、全球化 SaaS），上面的"一刀切 +08:00"方案就不太够了。这种情况下我的建议策略是：

第一，数据库底层统一使用 UTC。全局time_zone设为'+00:00'，所有TIMESTAMP字段在库里都按 UTC 存储。

第二，应用服务层在做数据展示时，根据用户所属时区进行转换。这个转换放在应用层做，而不是数据库层，因为应用层有完整的用户上下文，可以用统一的工具类搞定。

第三，如果一定要在数据库层做转换，可以用CONVERT_TZ()函数，但要注意时区表必须已加载，否则函数会返回 NULL。

这套方案的优点是逻辑清晰，缺点是应用层要写好时区转换工具类，且所有团队成员必须遵守同一约定，否则容易出现"某块功能忘了转换"的问题。

6.3 关于 MySQL 8.0 的默认时区变化

顺带提一下：MySQL 8.0 的默认行为相比 5.7 没有本质变化，time_zone默认仍然是SYSTEM。但在 MySQL 8.0.19 之后，JDBC 驱动（Connector/J 8.0.23+）对serverTimezone的解析逻辑有了一些调整，更加严格，不识别CST这种歧义缩写。所以从 5.7 升到 8.0、或从老版本 JDBC 升到新版 JDBC 的项目，更容易遇到时区相关报错。

升级前强烈建议先检查全局时区设置和连接串参数，避免升级窗口期出现时间类故障。更新 MySQL 属于敏感操作，务必详细阅读官方 Release Notes，明确行为变化，再决定是否继续。

6.4 我个人的兜底心得

最后分享一个个人习惯：每次搭一个新的 MySQL 环境，我做的第一件事不是配 buffer、不是建账号，而是直接检查time_zone：

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

三秒钟的时间，换来的是后面至少省掉一整天的排查时间。

这个习惯在我的团队里也被保留了下来——新同学入职后搭环境，第一条就是配置时区。时间问题看着小，但它会渗透到业务的每一个角落：订单、日志、监控、报表、定时任务……一旦错了，纠正数据远比纠正配置痛苦得多。

说到底，time_zone是一个"一次配错，全线飘红"的参数，但它也可以成为你环境配置里最具性价比的投入——五分钟的配置，换来生产环境的长治久安。