你有没有过这种经历某天凌晨被值班电话叫醒说订单报表时间对不上查了半天发现数据库时间和业务实际时间差着8个小时。我遇到过不止一次而且每次表现还不一样——有时是全部时间都偏有时是只有TIMESTAMP字段在偏DATETIME却好好的。排查MySQL时区问题绕不开三个东西操作系统时区、set global time_zone动态修改以及配置文件里的default-time-zone参数。这篇文章把我这些年攒下的时区修改经验和踩坑记录整理成一套可以直接参考的做法适合正在被时间对不上问题折磨的后端开发、运维和DBA也适合想从原理层面搞懂时区机制的人。1. 为什么数据库时间和本地时间对不上先定位时区在MySQL里的真实形态1.1 一个典型的“只差8小时”案例某一次模拟项目X的支付对账单总是比实际时间早8小时。业务方一口咬定是数据库的问题。我到现场先跑了一句SELECT NOW()返回的是正确时间再跑业务SQL时间又是错的。当时第一反应是连接层于是开了一个新连接直接查SELECT session.time_zone返回SYSTEM再查系统的date发现操作系统是UTC时间。问题基本定位MySQL的global时区没有显式设置全部走SYSTEM而SYSTEM是UTC。这类问题在“模板镜像服务器”上特别常见。很多团队用云厂商或机房里通用镜像装机镜像里的系统时区未必和业务时区一致。数据库装好后没有显式配置时区于是继承了一个UTC环境。应用层写时间的时候如果代码里是用本地时区生成字符串表面上是正常的一旦某天有人改成用数据库函数NOW()、CURRENT_TIMESTAMP或者触发器来写时间就突然出现8小时偏移。所以排查时区问题不要一上来就看代码先把整条链路的时间基准搞清楚。1.2 DATETIME和TIMESTAMP差8小时为什么只发生在部分字段上很多人在排查时发现同一张表里create_time错8小时pay_time却完全正常。这种差异往往不是时区没改而是这两个字段的类型不同。MySQL里时间类型最重要、也最容易被忽略的区别就是DATETIME和TIMESTAMP的存储机制。DATETIME存的是字面值。你写入2024-11-20 10:00:00查询出来就是2024-11-20 10:00:00跟会话时区没有任何关系。TIMESTAMP则完全不同它内部统一按UTC存储。写入时MySQL会先把你的值按“当前会话时区”换算成UTC查询时再按“当前会话时区”换算回来。举个例子假设会话时区是08:00你往TIMESTAMP字段写入2024-11-20 10:00:00底层实际上存的是2024-11-20 02:00:00这个UTC时刻。之后如果换一个00:00的会话去查结果会显示成2024-11-20 02:00:00。数据本身没有变变的是展示视角。用一个生活化类比DATETIME像商品包装上印好的生产日期印几点就是几点TIMESTAMP像称重电子秤上的克数你可以换算成公斤、斤、盎司底层的物理量不变但不同地区的人看到的结果不一样。很多人“改了时区后历史数据错乱了”其实不是数据被改而是TIMESTAMP列换了换算基准旧值按新规则展示后看起来全变了。1.3 三层时区变量系统、全局、会话的读取顺序MySQL的时区不是一个单点设置而是一个三级结构。system_time_zone是操作系统时区一般只读MySQL启动时如果没拿到显式配置最终就会落到它上面。global.time_zone是库级全局时区新建立的连接默认继承它。session.time_zone是当前会话时区默认继承全局值但也可以单独改只影响当前连接。可以用下面这条SQL一眼看全三个值SELECT system_time_zone AS sys_tz, global.time_zone AS g_tz, session.time_zone AS s_tz;实际查询时time_zone字段常见的值是SYSTEM、08:00、UTC。其中SYSTEM有特殊含义表示“我没有显式指定去问操作系统要”。所以当global和session都显示SYSTEM时真正决定时间显示的是操作系统时区。这就是为什么很多人用SET GLOBAL time_zone08:00后立刻查看当前会话还是SYSTEM——因为老连接压根没刷新。2. set global time_zone改了却不生效的三个真实原因2.1 一条看起来很对的命令为什么马上验证还是原样生产环境里救火我们一般先执行SET GLOBAL time_zone 08:00;执行完之后习惯性在当前连接里跑SHOW VARIABLES LIKE time_zone;结果还是SYSTEM。这时候容易得出一个错误结论命令没生效。实际上命令是生效了的只是它影响的不是你当前这个会话。MySQL的time_zone是会话级变量全局值只是“给未来新连接用的默认值”当前会话以及所有已经建立的连接它们持有的是各自进入连接时的会话时区不会因为全局值变化而被回溯修改。要验证全局值是否生效必须开一个“新的连接”。新连接里查SELECT session.time_zone;会发现已经变成08:00。如果你用的是连接池还要注意连接池里可能还躺着大量旧连接这些连接不会立刻刷新。所以修改完全局时区后应用侧经常要配合一次连接池重建或重启应用才能确保所有线程拿到新时区。2.2 重启即丢set global只改内存不改配置第二个容易踩的坑SET GLOBAL改的只是运行内存中的值。一旦mysqld重启它又回到启动参数或配置文件里定义的状态。假设配置里没写过时区相关项重启后global会重新变成SYSTEM也就回到操作系统时区。这种“救火成功重启复燃”的情况在运维中太常见了。动态修改适合临时救急不适合做长期状态管理。如果想让配置固化要么改配置文件里的default-time-zone要么在MySQL 8.0里用SET PERSIST。个人经验线上环境除非是临时解决线上问题否则我尽量不单独执行SET GLOBAL因为很容易忘记同步配置文件造成“为什么重启后又不对了”的二次事故。2.3 权限不足报错ERROR 1227是怎么回事另一个被忽略的点是权限。普通业务账号执行SET GLOBAL time_zone08:00;时经常会收到ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN privilege(s) for this operation。MySQL 5.7需要SUPER权限8.0引入了更细粒度的SYSTEM_VARIABLES_ADMIN权限。如果生产账号只授权了业务库的增删改查修改全局变量自然是失败的。我的建议是把时区变更当成一个正式的变更动作来做不走业务账号。运维或DBA使用带着SYSTEM_VARIABLES_ADMIN或SUPER权限的管理账号执行并记录操作时间、操作原因、影响范围。如果权限受限又确实需要临时修改可以和数据库负责人确认授权方案不要把这类命令塞进业务代码里自动执行。2.4 set global的正确使用姿势动态修改真正合适的场景是线上数据库无法马上重启但业务时间已经偏移需要立刻止血。操作顺序一般是-- 1. 确认当前值 SELECT global.time_zone; -- 2. 修改全局默认值让之后新建的连接拿到正确时区 SET GLOBAL time_zone 08:00; -- 3. 修改当前会话保证自己接下来的验证是干净的 SET time_zone 08:00; -- 4. 立即在同一个会话内验证 SELECT NOW(), UTC_TIMESTAMP();止血完成后别忘了补一道“持久化”工作否则下次重启问题还会回来。这正是下一节配置文件方案的价值。3. 配置文件default-time-zone把时区固化成永久的正确值3.1 写进哪个配置段写在哪个文件里持久化时区修改标准做法是在MySQL配置文件的[mysqld]段下加一行[mysqld] default-time-zone 08:00注意是mysqld段不是[client]也不是[mysql]。前者影响服务端后者只影响命令行客户端。写错段落是新手常用的错误改完配置文件重启后查SHOW VARIABLES LIKE time_zone;发现还是SYSTEM。配置文件位置因发行版而异。常见的有/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf等。有些系统里主配置会include额外目录下的文件比如/etc/mysql/conf.d/。可以用这种方式确认当前读取的配置路径mysqld --verbose --help | grep -A 1 default-time-zone或者my_print_defaults mysqld3.2 三种取值SYSTEM、固定偏移、命名时区default-time-zone支持三类值取值示例含义适用场景SYSTEM跟随操作系统时区默认值不推荐用于生产08:00固定偏移没有夏令时概念国内业务首选简单直接Asia/ShanghaiIANA命名时区有时区表支撑适合需要DST的海外部署命名时区不是装上就能用的。MySQL的mysql.time_zone_name表默认只有SYSTEM和UTC要支持Asia/Shanghai这类命名时区必须先加载系统时区表。常见做法是把本机/usr/share/zoneinfo下的时区数据导入MySQLmysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql加载完成后配置才能写成default-time-zone Asia/Shanghai。如果时区表没加载启动或修改变量时会报“Unknown or incorrect time zone”错误。国内业务有个实际情况东八区全年无夏令时固定偏移08:00和命名时区Asia/Shanghai在结果上完全等价。因此我建议能用偏移量就用偏移量少一份时区表依赖少一种故障可能。只有业务跨多个有时令规则的国家或地区时才需要引入命名时区。3.3 改配置文件的完整操作流程生产环境里我不建议只改配置文件因为配置不会立刻加载必须重启才能生效。更稳妥的流程分四步先用SET GLOBAL动态修改让新连接马上正确属于“在线止血”。修改配置文件写入default-time-zone让重启后依然正确属于“固化状态”。选择一个低峰窗口重启mysqld同时评估重启对现有连接的影响。重启后执行前面那三条SELECT确认值都没变。这里有个容易被低估的点重启MySQL会导致所有连接断开连接池里的连接会重新建立。如果应用没有合理的重连机制重启瞬间可能有一波“连接失败”的报错。所以实际操作上尽量在业务低峰期做并且先通知应用负责人。3.4 MySQL 8.0的SET PERSIST不用手改配置文件的持久化方案除了手改配置文件MySQL 8.0还提供了更现代化的持久化方式。SET PERSIST会同时修改运行时值并把变更写入mysqld-auto.cnf因此重启后依然生效。比如SET PERSIST time_zone 08:00;如果只想把参数写入持久化文件暂时不改变当前全局值可以用SET PERSIST_ONLY。这个功能的最大好处是避免手改配置文件时出现格式错误、段名错误这类粗心问题。不过mysqld-auto.cnf也是配置文件发布配置时需要一并纳入版本管理不然在某一台新机器上初始化MySQL时状态会和其他机器不一致。4. 改完怎么验证不要只会SHOW VARIABLES4.1 每次修改后都执行同一套验证SQL很多人在修改时区后只查一句SHOW VARIABLES LIKE time_zone;看到08:00就觉得没问题了。这远远不够。我更推荐下面的组合验证语句SELECT system_time_zone AS sys_tz, global.time_zone AS g_tz, session.time_zone AS s_tz, NOW() AS local_now, UTC_TIMESTAMP() AS utc_now, TIMEDIFF(NOW(), UTC_TIMESTAMP()) AS tz_offset;这里面最关键的是TIMEDIFF(NOW(), UTC_TIMESTAMP())。如果配置正确它应该返回08:00:00东八区。如果返回00:00:00说明当前会话时区实际是UTC。如果返回一个奇怪的小时数说明时区配置或系统时区有问题。这一条SQL能直接验证“当前连接真正使用的时区”而不是只看变量定义。4.2 观察到的值与问题层级的对应关系现象可能的根因sys_tz、g_tz、s_tz全是SYSTEM操作系统时区不对先改系统时区g_tz和s_tz不一致连接池或应用显式修改过会话时区g_tz和s_tz都是08:00但应用查询仍偏移连接串里的时区参数有问题重启后g_tz和s_tz回到SYSTEM配置未持久化缺default-time-zone设置用这张表去对照基本能缩小排查范围。值得强调的是“应用查询仍偏移”这一类因为服务端已经全对但应用侧的时间转换参数还会引入额外偏移这是下一章重点讲的内容。4.3 改完时区后历史TIMESTAMP数据会不会损坏这是一个经常引起恐慌的疑问。修改时区后用SQL查历史TIMESTAMP字段发现所有时间都变了8小时有人会以为数据被“改写”了。其实不是。TIMESTAMP底层存的是UTC时刻这个UTC时刻没有变变的是会话时区这个“展示规则”。查出不同的字符串本质上和“同一个时刻在北京叫20点在伦敦叫12点”一样不代表数据损坏。DATETIME字段更简单它存的就是字面量查询结果完全不受时区影响。所以只要搞清楚字段类型就不会被“时间错乱”的假象吓到。5. serverTimezone与连接串应用侧最容易漏掉的一环5.1 服务端全对应用读出来还是错的有一段时间我连续接到几个类似问题数据库服务器global.time_zone和session.time_zone都已经显示08:00直接跑MySQL命令行也正确但Java应用查出来的java.sql.Timestamp打印出来却差了8小时。最后定位到的问题是JDBC连接串。MySQL的驱动在建立连接时会和服务端协商时区。以Connector/J为例如果连接串里没有显式指定serverTimezone驱动通常会拿客户端JVM的默认时区去推测。应用服务器如果部署在UTC时区的容器里驱动就会按UTC解析数据库返回的时间于是一层正确的08:00在应用侧被硬生生掰回了UTC。这种“服务端正确、连接层错误”的问题最隐蔽。5.2 Java应用怎么配连接串Java连接串里建议显式加上serverTimezone参数jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseLegacyDatetimeCodefalseserverTimezone告诉驱动数据库服务器所在时区驱动就按这个基准解释数据库返回的时间。useLegacyDatetimeCodefalse在较新版本中也很常见它让驱动尽可能使用服务器时区语义而不是JVM默认时区。如果使用的是mysql-connector-j8.0及以上版本务必确认驱动行为和连接串参数的搭配。这里也顺便说一下如果应用和数据库都在东八区直接把连接串里的serverTimezone设为08:00或Asia/Shanghai通常就能解决。不要小看一个连接串参数它造成的偏移时间是实打实的。5.3 Go、Python等语言侧同样要做时区约定Java不是唯一受连接时区影响的场景。Go的数据库驱动比如go-sql-driver/mysqlDSN里通常要设置loc参数例如locLocal或者locAsia%2FShanghai否则解析时间可能落在UTC。Python的PyMySQL则常见于连接后立即执行SET time_zone 08:00或者依赖系统时区。这些语言差异背后是同一件事应用必须知道数据库告诉它的时间是什么基准否则任何一层误解都会产生偏移。我的经验是不要让每个应用开发者自己记时区规则最好在初始化连接时统一设置或者封装一个公共的数据访问层把“连接后设置时间会话”这类操作收拢到一个地方。5.4 防止双重偏移的铁律所谓双重偏移是指数据库已经存了正确值应用在解析时间时按A时区理解打印或展示时又按B时区格式化最后结果既不是A也不是B。比如数据库中存的是东八区时间驱动却按UTC解析然后代码里又调用toLocalDateTime()转换了一次时间就偏出两倍。我的铁律是全链路尽量只保留一个时区基准。要么数据库、连接串、应用运行环境全部用UTC在展示层转成东八区要么全部用东八区。最怕的是数据库用东八区、容器用UTC、JDBC参数不写、业务代码再自作主张转一次。四个环节只要有两个基准不一致时间就一定会错。6. 一套小而稳的时区治理清单从系统到应用一步到位6.1 排查顺序先看系统再看数据库最后看连接处理时区问题我有一套固定的排查顺序基本不会跑偏在数据库机器上执行date确认操作系统时区是不是业务期望的时区。执行SELECT system_time_zone, global.time_zone, session.time_zone;确认MySQL三个值分别是什么。执行SELECT NOW(), UTC_TIMESTAMP();确认实际时间偏移。检查连接串和数据库驱动参数确认连接层时区一致。最后再看业务代码在读取和写入时间时有没有额外转换。按这个顺序走大多数“时间差8小时”的问题能在前四步定位。不要一开始就翻代码代码在大多数情况下是无辜的。6.2 修改三步走急救、持久化、验证急救SET GLOBAL time_zone 08:00;主要为了不重启就让新连接生效。持久化配置文件写[mysqld] default-time-zone 08:00或MySQL 8.0执行SET PERSIST time_zone 08:00;。验证按第4章的组合SQL执行一遍并重启一次或至少确认持久化文件内容正确。这个三步走方案可以覆盖绝大多数业务场景。如果你们公司有自动化运维平台建议把时区值做成一个标准化基线所有新装的MySQL实例默认就带default-time-zone 08:00而不是等出问题再改。6.3 最后分享一个实际配置片段下面是一段我在生产环境常用到的配置组合它把操作系统、MySQL全局、会话默认值都收敛到了东八区[mysqld] default-time-zone 08:00系统层面我用系统初始化脚本统一设置timedatectl set-timezone Asia/Shanghai这样安排之后新初始化出来的数据库实例一出生就在正确的时区上省掉了后续所有救火操作。如果你手头正好有一台已经跑了一段业务的数据库只要确认业务没有依赖UTC做跨时区结算就可以按本文的流程平滑调整。我实际处理过的项目里按这套方法调整后订单时间、日志时间、报表时间基本都能一次对齐。
你有没有过这种经历某天凌晨被值班电话叫醒说订单报表时间对不上查了半天发现数据库时间和业务实际时间差着8个小时。我遇到过不止一次而且每次表现还不一样——有时是全部时间都偏有时是只有TIMESTAMP字段在偏DATETIME却好好的。排查MySQL时区问题绕不开三个东西操作系统时区、set global time_zone动态修改以及配置文件里的default-time-zone参数。这篇文章把我这些年攒下的时区修改经验和踩坑记录整理成一套可以直接参考的做法适合正在被时间对不上问题折磨的后端开发、运维和DBA也适合想从原理层面搞懂时区机制的人。1. 为什么数据库时间和本地时间对不上先定位时区在MySQL里的真实形态1.1 一个典型的“只差8小时”案例某一次模拟项目X的支付对账单总是比实际时间早8小时。业务方一口咬定是数据库的问题。我到现场先跑了一句SELECT NOW()返回的是正确时间再跑业务SQL时间又是错的。当时第一反应是连接层于是开了一个新连接直接查SELECT session.time_zone返回SYSTEM再查系统的date发现操作系统是UTC时间。问题基本定位MySQL的global时区没有显式设置全部走SYSTEM而SYSTEM是UTC。这类问题在“模板镜像服务器”上特别常见。很多团队用云厂商或机房里通用镜像装机镜像里的系统时区未必和业务时区一致。数据库装好后没有显式配置时区于是继承了一个UTC环境。应用层写时间的时候如果代码里是用本地时区生成字符串表面上是正常的一旦某天有人改成用数据库函数NOW()、CURRENT_TIMESTAMP或者触发器来写时间就突然出现8小时偏移。所以排查时区问题不要一上来就看代码先把整条链路的时间基准搞清楚。1.2 DATETIME和TIMESTAMP差8小时为什么只发生在部分字段上很多人在排查时发现同一张表里create_time错8小时pay_time却完全正常。这种差异往往不是时区没改而是这两个字段的类型不同。MySQL里时间类型最重要、也最容易被忽略的区别就是DATETIME和TIMESTAMP的存储机制。DATETIME存的是字面值。你写入2024-11-20 10:00:00查询出来就是2024-11-20 10:00:00跟会话时区没有任何关系。TIMESTAMP则完全不同它内部统一按UTC存储。写入时MySQL会先把你的值按“当前会话时区”换算成UTC查询时再按“当前会话时区”换算回来。举个例子假设会话时区是08:00你往TIMESTAMP字段写入2024-11-20 10:00:00底层实际上存的是2024-11-20 02:00:00这个UTC时刻。之后如果换一个00:00的会话去查结果会显示成2024-11-20 02:00:00。数据本身没有变变的是展示视角。用一个生活化类比DATETIME像商品包装上印好的生产日期印几点就是几点TIMESTAMP像称重电子秤上的克数你可以换算成公斤、斤、盎司底层的物理量不变但不同地区的人看到的结果不一样。很多人“改了时区后历史数据错乱了”其实不是数据被改而是TIMESTAMP列换了换算基准旧值按新规则展示后看起来全变了。1.3 三层时区变量系统、全局、会话的读取顺序MySQL的时区不是一个单点设置而是一个三级结构。system_time_zone是操作系统时区一般只读MySQL启动时如果没拿到显式配置最终就会落到它上面。global.time_zone是库级全局时区新建立的连接默认继承它。session.time_zone是当前会话时区默认继承全局值但也可以单独改只影响当前连接。可以用下面这条SQL一眼看全三个值SELECT system_time_zone AS sys_tz, global.time_zone AS g_tz, session.time_zone AS s_tz;实际查询时time_zone字段常见的值是SYSTEM、08:00、UTC。其中SYSTEM有特殊含义表示“我没有显式指定去问操作系统要”。所以当global和session都显示SYSTEM时真正决定时间显示的是操作系统时区。这就是为什么很多人用SET GLOBAL time_zone08:00后立刻查看当前会话还是SYSTEM——因为老连接压根没刷新。2. set global time_zone改了却不生效的三个真实原因2.1 一条看起来很对的命令为什么马上验证还是原样生产环境里救火我们一般先执行SET GLOBAL time_zone 08:00;执行完之后习惯性在当前连接里跑SHOW VARIABLES LIKE time_zone;结果还是SYSTEM。这时候容易得出一个错误结论命令没生效。实际上命令是生效了的只是它影响的不是你当前这个会话。MySQL的time_zone是会话级变量全局值只是“给未来新连接用的默认值”当前会话以及所有已经建立的连接它们持有的是各自进入连接时的会话时区不会因为全局值变化而被回溯修改。要验证全局值是否生效必须开一个“新的连接”。新连接里查SELECT session.time_zone;会发现已经变成08:00。如果你用的是连接池还要注意连接池里可能还躺着大量旧连接这些连接不会立刻刷新。所以修改完全局时区后应用侧经常要配合一次连接池重建或重启应用才能确保所有线程拿到新时区。2.2 重启即丢set global只改内存不改配置第二个容易踩的坑SET GLOBAL改的只是运行内存中的值。一旦mysqld重启它又回到启动参数或配置文件里定义的状态。假设配置里没写过时区相关项重启后global会重新变成SYSTEM也就回到操作系统时区。这种“救火成功重启复燃”的情况在运维中太常见了。动态修改适合临时救急不适合做长期状态管理。如果想让配置固化要么改配置文件里的default-time-zone要么在MySQL 8.0里用SET PERSIST。个人经验线上环境除非是临时解决线上问题否则我尽量不单独执行SET GLOBAL因为很容易忘记同步配置文件造成“为什么重启后又不对了”的二次事故。2.3 权限不足报错ERROR 1227是怎么回事另一个被忽略的点是权限。普通业务账号执行SET GLOBAL time_zone08:00;时经常会收到ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN privilege(s) for this operation。MySQL 5.7需要SUPER权限8.0引入了更细粒度的SYSTEM_VARIABLES_ADMIN权限。如果生产账号只授权了业务库的增删改查修改全局变量自然是失败的。我的建议是把时区变更当成一个正式的变更动作来做不走业务账号。运维或DBA使用带着SYSTEM_VARIABLES_ADMIN或SUPER权限的管理账号执行并记录操作时间、操作原因、影响范围。如果权限受限又确实需要临时修改可以和数据库负责人确认授权方案不要把这类命令塞进业务代码里自动执行。2.4 set global的正确使用姿势动态修改真正合适的场景是线上数据库无法马上重启但业务时间已经偏移需要立刻止血。操作顺序一般是-- 1. 确认当前值 SELECT global.time_zone; -- 2. 修改全局默认值让之后新建的连接拿到正确时区 SET GLOBAL time_zone 08:00; -- 3. 修改当前会话保证自己接下来的验证是干净的 SET time_zone 08:00; -- 4. 立即在同一个会话内验证 SELECT NOW(), UTC_TIMESTAMP();止血完成后别忘了补一道“持久化”工作否则下次重启问题还会回来。这正是下一节配置文件方案的价值。3. 配置文件default-time-zone把时区固化成永久的正确值3.1 写进哪个配置段写在哪个文件里持久化时区修改标准做法是在MySQL配置文件的[mysqld]段下加一行[mysqld] default-time-zone 08:00注意是mysqld段不是[client]也不是[mysql]。前者影响服务端后者只影响命令行客户端。写错段落是新手常用的错误改完配置文件重启后查SHOW VARIABLES LIKE time_zone;发现还是SYSTEM。配置文件位置因发行版而异。常见的有/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf等。有些系统里主配置会include额外目录下的文件比如/etc/mysql/conf.d/。可以用这种方式确认当前读取的配置路径mysqld --verbose --help | grep -A 1 default-time-zone或者my_print_defaults mysqld3.2 三种取值SYSTEM、固定偏移、命名时区default-time-zone支持三类值取值示例含义适用场景SYSTEM跟随操作系统时区默认值不推荐用于生产08:00固定偏移没有夏令时概念国内业务首选简单直接Asia/ShanghaiIANA命名时区有时区表支撑适合需要DST的海外部署命名时区不是装上就能用的。MySQL的mysql.time_zone_name表默认只有SYSTEM和UTC要支持Asia/Shanghai这类命名时区必须先加载系统时区表。常见做法是把本机/usr/share/zoneinfo下的时区数据导入MySQLmysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql加载完成后配置才能写成default-time-zone Asia/Shanghai。如果时区表没加载启动或修改变量时会报“Unknown or incorrect time zone”错误。国内业务有个实际情况东八区全年无夏令时固定偏移08:00和命名时区Asia/Shanghai在结果上完全等价。因此我建议能用偏移量就用偏移量少一份时区表依赖少一种故障可能。只有业务跨多个有时令规则的国家或地区时才需要引入命名时区。3.3 改配置文件的完整操作流程生产环境里我不建议只改配置文件因为配置不会立刻加载必须重启才能生效。更稳妥的流程分四步先用SET GLOBAL动态修改让新连接马上正确属于“在线止血”。修改配置文件写入default-time-zone让重启后依然正确属于“固化状态”。选择一个低峰窗口重启mysqld同时评估重启对现有连接的影响。重启后执行前面那三条SELECT确认值都没变。这里有个容易被低估的点重启MySQL会导致所有连接断开连接池里的连接会重新建立。如果应用没有合理的重连机制重启瞬间可能有一波“连接失败”的报错。所以实际操作上尽量在业务低峰期做并且先通知应用负责人。3.4 MySQL 8.0的SET PERSIST不用手改配置文件的持久化方案除了手改配置文件MySQL 8.0还提供了更现代化的持久化方式。SET PERSIST会同时修改运行时值并把变更写入mysqld-auto.cnf因此重启后依然生效。比如SET PERSIST time_zone 08:00;如果只想把参数写入持久化文件暂时不改变当前全局值可以用SET PERSIST_ONLY。这个功能的最大好处是避免手改配置文件时出现格式错误、段名错误这类粗心问题。不过mysqld-auto.cnf也是配置文件发布配置时需要一并纳入版本管理不然在某一台新机器上初始化MySQL时状态会和其他机器不一致。4. 改完怎么验证不要只会SHOW VARIABLES4.1 每次修改后都执行同一套验证SQL很多人在修改时区后只查一句SHOW VARIABLES LIKE time_zone;看到08:00就觉得没问题了。这远远不够。我更推荐下面的组合验证语句SELECT system_time_zone AS sys_tz, global.time_zone AS g_tz, session.time_zone AS s_tz, NOW() AS local_now, UTC_TIMESTAMP() AS utc_now, TIMEDIFF(NOW(), UTC_TIMESTAMP()) AS tz_offset;这里面最关键的是TIMEDIFF(NOW(), UTC_TIMESTAMP())。如果配置正确它应该返回08:00:00东八区。如果返回00:00:00说明当前会话时区实际是UTC。如果返回一个奇怪的小时数说明时区配置或系统时区有问题。这一条SQL能直接验证“当前连接真正使用的时区”而不是只看变量定义。4.2 观察到的值与问题层级的对应关系现象可能的根因sys_tz、g_tz、s_tz全是SYSTEM操作系统时区不对先改系统时区g_tz和s_tz不一致连接池或应用显式修改过会话时区g_tz和s_tz都是08:00但应用查询仍偏移连接串里的时区参数有问题重启后g_tz和s_tz回到SYSTEM配置未持久化缺default-time-zone设置用这张表去对照基本能缩小排查范围。值得强调的是“应用查询仍偏移”这一类因为服务端已经全对但应用侧的时间转换参数还会引入额外偏移这是下一章重点讲的内容。4.3 改完时区后历史TIMESTAMP数据会不会损坏这是一个经常引起恐慌的疑问。修改时区后用SQL查历史TIMESTAMP字段发现所有时间都变了8小时有人会以为数据被“改写”了。其实不是。TIMESTAMP底层存的是UTC时刻这个UTC时刻没有变变的是会话时区这个“展示规则”。查出不同的字符串本质上和“同一个时刻在北京叫20点在伦敦叫12点”一样不代表数据损坏。DATETIME字段更简单它存的就是字面量查询结果完全不受时区影响。所以只要搞清楚字段类型就不会被“时间错乱”的假象吓到。5. serverTimezone与连接串应用侧最容易漏掉的一环5.1 服务端全对应用读出来还是错的有一段时间我连续接到几个类似问题数据库服务器global.time_zone和session.time_zone都已经显示08:00直接跑MySQL命令行也正确但Java应用查出来的java.sql.Timestamp打印出来却差了8小时。最后定位到的问题是JDBC连接串。MySQL的驱动在建立连接时会和服务端协商时区。以Connector/J为例如果连接串里没有显式指定serverTimezone驱动通常会拿客户端JVM的默认时区去推测。应用服务器如果部署在UTC时区的容器里驱动就会按UTC解析数据库返回的时间于是一层正确的08:00在应用侧被硬生生掰回了UTC。这种“服务端正确、连接层错误”的问题最隐蔽。5.2 Java应用怎么配连接串Java连接串里建议显式加上serverTimezone参数jdbc:mysql://127.0.0.1:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseLegacyDatetimeCodefalseserverTimezone告诉驱动数据库服务器所在时区驱动就按这个基准解释数据库返回的时间。useLegacyDatetimeCodefalse在较新版本中也很常见它让驱动尽可能使用服务器时区语义而不是JVM默认时区。如果使用的是mysql-connector-j8.0及以上版本务必确认驱动行为和连接串参数的搭配。这里也顺便说一下如果应用和数据库都在东八区直接把连接串里的serverTimezone设为08:00或Asia/Shanghai通常就能解决。不要小看一个连接串参数它造成的偏移时间是实打实的。5.3 Go、Python等语言侧同样要做时区约定Java不是唯一受连接时区影响的场景。Go的数据库驱动比如go-sql-driver/mysqlDSN里通常要设置loc参数例如locLocal或者locAsia%2FShanghai否则解析时间可能落在UTC。Python的PyMySQL则常见于连接后立即执行SET time_zone 08:00或者依赖系统时区。这些语言差异背后是同一件事应用必须知道数据库告诉它的时间是什么基准否则任何一层误解都会产生偏移。我的经验是不要让每个应用开发者自己记时区规则最好在初始化连接时统一设置或者封装一个公共的数据访问层把“连接后设置时间会话”这类操作收拢到一个地方。5.4 防止双重偏移的铁律所谓双重偏移是指数据库已经存了正确值应用在解析时间时按A时区理解打印或展示时又按B时区格式化最后结果既不是A也不是B。比如数据库中存的是东八区时间驱动却按UTC解析然后代码里又调用toLocalDateTime()转换了一次时间就偏出两倍。我的铁律是全链路尽量只保留一个时区基准。要么数据库、连接串、应用运行环境全部用UTC在展示层转成东八区要么全部用东八区。最怕的是数据库用东八区、容器用UTC、JDBC参数不写、业务代码再自作主张转一次。四个环节只要有两个基准不一致时间就一定会错。6. 一套小而稳的时区治理清单从系统到应用一步到位6.1 排查顺序先看系统再看数据库最后看连接处理时区问题我有一套固定的排查顺序基本不会跑偏在数据库机器上执行date确认操作系统时区是不是业务期望的时区。执行SELECT system_time_zone, global.time_zone, session.time_zone;确认MySQL三个值分别是什么。执行SELECT NOW(), UTC_TIMESTAMP();确认实际时间偏移。检查连接串和数据库驱动参数确认连接层时区一致。最后再看业务代码在读取和写入时间时有没有额外转换。按这个顺序走大多数“时间差8小时”的问题能在前四步定位。不要一开始就翻代码代码在大多数情况下是无辜的。6.2 修改三步走急救、持久化、验证急救SET GLOBAL time_zone 08:00;主要为了不重启就让新连接生效。持久化配置文件写[mysqld] default-time-zone 08:00或MySQL 8.0执行SET PERSIST time_zone 08:00;。验证按第4章的组合SQL执行一遍并重启一次或至少确认持久化文件内容正确。这个三步走方案可以覆盖绝大多数业务场景。如果你们公司有自动化运维平台建议把时区值做成一个标准化基线所有新装的MySQL实例默认就带default-time-zone 08:00而不是等出问题再改。6.3 最后分享一个实际配置片段下面是一段我在生产环境常用到的配置组合它把操作系统、MySQL全局、会话默认值都收敛到了东八区[mysqld] default-time-zone 08:00系统层面我用系统初始化脚本统一设置timedatectl set-timezone Asia/Shanghai这样安排之后新初始化出来的数据库实例一出生就在正确的时区上省掉了后续所有救火操作。如果你手头正好有一台已经跑了一段业务的数据库只要确认业务没有依赖UTC做跨时区结算就可以按本文的流程平滑调整。我实际处理过的项目里按这套方法调整后订单时间、日志时间、报表时间基本都能一次对齐。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
