说真的第一次在生产环境踩到 MySQL 时间错乱的时候我整整排查了一个下午。现象非常诡异应用日志里打印的时间是对的写入数据库再查出来却差了 13 个小时换了连接串之后又变成差 8 个小时。后来才发现问题出在 MySQL 时区参数 time_zone 上。这个参数看起来不起眼但它决定了服务器怎么解析时间、怎么给客户端返回时间一旦和操作系统、应用层、连接串各玩各的时间数据就全乱套了。这篇文章我想把 time_zone 这个参数从头到尾讲透它管什么、怎么查怎么设、有哪些坑、怎么排查。不管你是刚入职的新人还是被线上时间问题折磨过的老油条都应该能从中找到自己想要的东西。1. 被时间差逼疯的排查经历time_zone 到底管住了什么先讲个真实案例。我之前帮一个朋友团队看问题他们的业务是电商订单数据库里有一张订单表里面有create_time字段用的是DATETIME类型。某天运营反馈后台看到的订单创建时间和用户下单时间差了 8 个小时。我上去一看应用服务器在东八区数据库服务器也设置了东八区但 MySQL 里SHOW VARIABLES LIKE time_zone;查出来却是SYSTEM然后再查操作系统时区才发现这台数据库服务器的/etc/localtime指向的是UTC。也就是说MySQL 跟着操作系统用了 UTC 时间而应用层是东八区两边各按各的来数据自然对不上。这个案例里有一个关键点time_zone这个参数控制的是 MySQL 服务器端的时间解读方式。它影响三个层面的行为服务器内置时间函数的返回值比如NOW()、CURRENT_TIMESTAMP、CURDATE()。对TIMESTAMP类型字段的读写转换。FROM_UNIXTIME()、UNIX_TIMESTAMP()这类转换函数的结果。很多人会把time_zone和存储时区混为一谈。实际上MySQL 的日期时间类型里只有TIMESTAMP会做时区转换DATETIME完全不做。这两者的差别才是理解 time_zone 行为的第一块敲门砖。1.1 TIMESTAMP 和 DATETIME时区影响的边界在哪里TIMESTAMP的内部存储形式是 UTC 时间戳从1970-01-01 00:00:00 UTC开始算起的秒数。你在东八区写入2024-06-01 12:00:00MySQL 会先把它换算成 UTC 时间也就是2024-06-01 04:00:00存进去等客户端查询时再根据当前会话的time_zone把 UTC 时间换算回本地时间显示。DATETIME就简单粗暴存什么就是什么。你写入2024-06-01 12:00:00查出来还是这个值中间不做任何时区换算。所以你会看到这样的场景一张表里既有TIMESTAMP又有DATETIME如果会话时区从东八区改成 UTCTIMESTAMP字段查出来的值会少 8 个小时而DATETIME字段纹丝不动。这不是数据坏了是类型设计之初就决定的机制。生产环境里大量时间错乱问题的根源都可以归结为写入端的会话时区、查询端的会话时区、以及应用层所理解的时区三者没有统一。要么大家都用东八区要么大家都用 UTC只要有一端不一致TIMESTAMP就会自动帮你换算出一个错误的本地时间。1.2 一次写入和读取时间到底被转换了几次假设你的应用服务器、MySQL 会话时区都是东八区08:00用户在 18:00 下单应用拼接 SQL 写入create_time。如果字段是DATETIME直接存入2024-06-01 18:00:00查询时原样返回全程零转换。如果字段是TIMESTAMPMySQL 把18:00:00理解成东八区时间转成 UTC 存成2024-06-01 10:00:00对应的时间戳查询时再把时间戳换算成08:00的本地时间显示18:00:00。从用户视角看两种类型在大家都用东八区的情况下毫无差别。但一旦会话时区变成09:00TIMESTAMP查出来就会变成19:00:00DATETIME还是18:00:00。这就是我想表达的重点time_zone不是要不要存时区的问题而是MySQL 如何把时间戳和本地时间做双向映射的问题。搞懂了这一层后面所有参数设置和坑就都顺理成章了。2. 三个层级的时区变量global、session、SYSTEM 的读取规则MySQL 的time_zone不是孤零零的一个值它分全局变量和会话变量而且还有一个兜底的 SYSTEM 特殊值。不少人在这上面栽过跟头明明执行了SET GLOBAL time_zone 08:00;当前连接查出来还是老样子就觉得命令没生效。其实不是没生效是没搞懂作用范围。2.1 变量读取顺序session 覆盖 globalglobal 兜底你可以用下面两条命令分别查看全局和当前会话的时区SELECT GLOBAL.time_zone; SELECT SESSION.time_zone;或者用一条命令一次性看两个SELECT GLOBAL.time_zone AS global_tz, SESSION.time_zone AS session_tz;规则很简单新建立的连接会继承全局变量GLOBAL.time_zone作为自己的会话变量SESSION.time_zone但当前连接里如果单独执行过SET time_zone ...就会覆盖继承的值只对这个连接生效。所以当你SET GLOBAL time_zone 08:00;之后已经存在的旧连接不会变只有新连接才会拿到新值。如果你在命令行客户端里执行完全局设置后立刻同一条会话去查询看到的值还是旧的这就是很多人误以为没生效的原因。2.2 改全局却不生效的典型误操作除了作用域问题还有一个权限问题。MySQL 8.0 里设置全局变量需要SYSTEM_VARIABLES_ADMIN权限或更高权限MySQL 5.7 里对应的是SUPER权限。如果你用的是权限受限的业务账号去执行SET GLOBAL time_zone 08:00;会直接报错ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_VARIABLES_ADMIN or SUPER privilege(s) for this operation不少人在这个错误上浪费时间以为语法写错了其实纯粹是账号权限不够换成 root 或者有管理员权限的账号就好。另外SET GLOBAL只在运行期生效数据库一旦重启就会回到配置文件的设置。如果只想临时验证没问题但要长期生效必须把配置写进 MySQL 配置文件具体写法见下一章。2.3 为什么默认值是 SYSTEM 而不是某个固定时区MySQL 的time_zone默认值是SYSTEM意思是跟随 MySQL 所在操作系统的时区设置。MySQL 启动时会读取操作系统的当前时区并缓存起来之后NOW()、TIMESTAMP换算都以这个缓存值为准。这里有一个很隐蔽的坑操作系统时区修改后MySQL 不会自动跟着变。比如你用timedatectl set-timezone Asia/Shanghai改了系统时区正在运行的 MySQL 仍会使用启动时缓存的那个时区必须重启 MySQL 才能让它重新读取。更常见的是 Docker 场景。官方mysql镜像默认的容器内时区是 UTC如果你没有挂载/etc/localtime或者设置TZ环境变量那么容器里的 MySQL 的time_zone就是SYSTEMSYSTEM 对应的又是 UTC。你在宿主机看起来是东八区容器里却按 UTC 走时间自然差 8 个小时。提示开机后第一件事先跑一遍SELECT GLOBAL.time_zone, SESSION.time_zone;再确认一下操作系统的date %Z把这两层关系看清楚能省掉后面 80% 的排查时间。3. time_zone 的设置方式会话、全局、配置文件各有各的坑设置time_zone的方式大致有三种会话级、全局级、配置文件持久化。它们适用场景不一样坑也不一样。我按我平时的工作习惯逐个讲。3.1 会话级设置临时改随连随走只想让当前连接临时换一个时区直接执行SET time_zone 08:00; -- 等价于 SET SESSION time_zone 08:00;SET time_zone ...默认就是设置会话变量不需要额外加SESSION关键字。它的生效范围是当前连接连接关闭就还原。适合在跑某些一次性脚本时想让NOW()或TIMESTAMP输出符合某个时区又不想影响别人的场景。比如在数据订正脚本里你想把只读库里的TIMESTAMP字段按东八区导出来先执行SET time_zone 08:00;再SELECT结果就会按东八区展示了。3.2 全局级设置在线生效重启丢失全局设置用GLOBAL关键字SET GLOBAL time_zone 08:00;它会让之后新建的连接使用新时区正在运行的连接不受影响。想验证有没有生效新开一个连接再查SELECT GLOBAL.time_zone, SESSION.time_zone;全局设置的优点是零停机、不用重启服务适合在排查时间问题时快速做线上验证。缺点是重启后失效必须配合配置文件持久化。3.3 配置文件持久化default-time-zone 才是正解这是我觉得最值得强调的一个点在 MySQL 配置文件my.cnf或my.ini里用于设置时区的选项名是default-time-zone不是time_zone。正确的写法是在[mysqld]段下[mysqld] default-time-zone 08:00如果你写成[mysqld] time_zone 08:00就可能遇到两种情况MySQL 启动时直接报错具体取决于版本对未知选项的解析方式或者配置被忽略重启后时区还原。很多人把配置写进去后重启发现time_zone没变第一反应是重启没生效其实很可能就是整个选项名写错了。如果你用命令行方式启动 mysqld对应参数是mysqld --default-time-zone08:00 --socket/tmp/mysql.sock另外要注意如果服务器上部署了多个 MySQL 实例每个实例都有自己的配置文件别改错文件。用下面的命令可以确认实际加载的配置文件路径mysqld --verbose --help 2/dev/null | grep -A 1 Default options配置文件修改完之后需要重启 MySQL 才能让所有连接统一拿到新时区。所以我的建议是先用SET GLOBAL验证业务影响确认无误后再写配置文件做持久化最后选低峰期重启一次做兜底。3.4 偏移量写法和命名时区的区别设置time_zone时值可以是固定偏移量也可以是命名时区-- 固定偏移量 SET time_zone 08:00; SET time_zone -05:30; -- 命名时区依赖时区表 SET time_zone Asia/Shanghai; SET time_zone America/New_York;固定偏移量写法不依赖任何额外数据表MySQL 直接按给定偏移量转换简单直接适合国内绝大多数只使用东八区的业务。命名时区如果要生效前提是 MySQL 的时区表mysql.time_zone*系列表已经加载了数据否则会报错ERROR 1298 (HY000): Unknown or incorrect time zone: Asia/Shanghai这一块内容比较深单独开一节讲。4. 命名时区与时区表平时用不到一踩就是大坑很多从没接触过时区表的人会问为什么我在配置文件里写了default-time-zone Asia/ShanghaiMySQL 就启动不了了为什么执行SET time_zone Asia/Shanghai会报Unknown or incorrect time zone答案很简单MySQL 默认安装并不会加载操作系统时区数据。你看到mysql.time_zone_name表是空的或者整个库里根本没有相关表数据Asia/Shanghai这样的名字自然无法识别。4.1 用 mysql_tzinfo_to_sql 加载时区数据标准做法是使用 MySQL 自带的mysql_tzinfo_to_sql工具把操作系统的时区数据导入 MySQLmysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql导入后可以验证一下SELECT COUNT(*) FROM mysql.time_zone; SELECT * FROM mysql.time_zone_name WHERE Name Asia/Shanghai;正常情况下mysql.time_zone里有几百条时区记录。之后就可以正常使用SET time_zone Asia/Shanghai;或者在配置文件中写[mysqld] default-time-zone Asia/Shanghai要注意的是操作系统/usr/share/zoneinfo目录的时区数据如果很旧可能导致导入的夏令时规则过时。生产环境建议在操作系统层面保持更新再重新导入一次。4.2 偏移量写法和命名时区的本质差异固定偏移量08:00是死的它只代表一个固定的时间偏移不存在夏令时概念。命名时区Asia/Shanghai是活的它包含该地区的历史和当前时区规则MySQL 会按照规则表自动处理夏令时切换。中国从 1991 年之后就不再实行夏令时所以Asia/Shanghai实际上常年等价于08:00。但对涉及美国、欧洲业务的系统来说America/New_York、Europe/London这类命名时区会随夏令时切换而改变偏移这才是命名时区真正的价值所在。4.3 夏令时切换的真实影响举一个具体例子美国 2024 年夏令时从 3 月第二个周日凌晨 2:00 开始时钟拨到 3:00也就是说02:00:00到02:59:59这一个小时在当天是不存在的。如果你把time_zone设置为America/New_York并且业务涉及这个时间段写入的TIMESTAMP数据就会遇到比较棘手的情况这个小时的本地时间无法映射到真实 UTC 时间MySQL 的处理方式可能与你预期不同可能导致数据在夏令时切换那一刻出现异常展示。反过来说春季切换时虽然少了一个小时但多出来的重复小时也有问题秋季切换那天01:00:00到01:59:59会经历两次。同一个本地时间对应两个不同的 UTC 时刻TIMESTAMP换算时会因为会话时区设置的不同产生两套结果。我接触过的一些跨境电商团队为了避免这类问题直接在数据库层使用00:00或08:00固定偏移把夏令时逻辑完全交给上层应用处理。这种做法牺牲了数据库层面的可读性但换来了确定性对交易类系统来说往往更稳妥。提示如果业务不跨夏令时地区强烈建议直接用固定偏移量。不是命名时区不好而是多一层时区规则就会多一层不可控风险尤其当上游时区数据源没有及时更新的时候。5. 连接层的二次时区JDBC、客户端工具为什么总跟你作对很多人会忽略一个事实time_zone是 MySQL 服务器端的参数但你的应用不一定只和服务器打交道。JDBC 驱动、ORM 框架、数据库客户端工具都有自己的时区处理逻辑。服务器端时区设置正确了连接层如果没跟上照样出乱子。5.1 经典报错serverTimezone 参数与 MySQL time_zone 的关系用 JDBC 连接 MySQL 时最经典的报错长这样java.sql.SQLException: The server time zone value Öйú±ê׼ʱ¼ä is unrecognized or represents more than one time zone.这个报错里那段乱码实际上是 GBK 编码的中国标准时间在客户端被错误解码后的样子。MySQL 服务器返回了操作系统层面的时区描述而 Connector/J 无法识别。解决办法是在 JDBC URL 中显式指定serverTimezonejdbc:mysql://localhost:3306/dbname?serverTimezoneAsia/ShanghaiuseSSLfalse也可以写成 GMT 偏移量jdbc:mysql://localhost:3306/dbname?serverTimezoneGMT%2B8注意 URL 里号需要编码成%2B否则可能被解析成空格导致时区设置无效。serverTimezone参数的本质是告诉 JDBC 驱动MySQL 服务器当前使用的是什么时区。 驱动拿到这个值后会在应用 JVM 时区与 MySQL 时区之间做一次转换。如果你把serverTimezoneAsia/Shanghai写死但 MySQL 服务器本身是 UTC那么 JDBC 会在两边之间强行加一道换算结果就是应用读到的时间整体偏移。我见过不止一次这样的场景团队把serverTimezone设置成Asia/Shanghai又觉得不放心额外给 MySQL 也设置了08:00结果两边一致数据正常后来有人把 MySQL 全局时区调成了00:00但 JDBC 连接串没改第二天全线时间差了 8 个小时。把这个连接串参数和服务器参数视为同一个系统的两个半场非常关键。5.2 客户端工具和 ORM 的干扰因素不只是 JDBC。Navicat、DBeaver、DataGrip 这类图形化客户端默认也会按照本机的时区来显示TIMESTAMP类型的值。你在服务器上执行SELECT NOW();得到一个时间客户端工具里看到的时间可能不一样因为工具本身又做了一层转换。ORM 层面也常有干扰。Hibernate、MyBatis 等框架一般不会主动改时区但如果应用的 JVM 默认时区不是东八区java.util.Date在序列化和反序列化时就会产生偏差。排查时一定要把 JVM 时区也纳进来java -XX:PrintFlagsFinal -version | grep -i timezone正常地排查链路应该是操作系统时区 → MySQL 全局/会话时区 → JDBCserverTimezone→ 应用 JVM 时区四层保持一致才能保证TIMESTAMP从写入到读取一路无偏移。6. 一次线上时间错乱问题的完整排查过程前面讲了不少原理这一节我把一次完整的线上排查过程原原本本写出来方便你照着这个思路去套自己的场景。6.1 现象用户下单时间比实际提前了 13 小时当时业务反馈运营后台看到的订单创建时间是2024-05-20 05:30:00实际下单时间是当天18:30:00差了 13 个小时。13 个小时这个数字很有迷惑性不是标准的 8 小时所以一开始大家都以为是数据问题对着 SQL 和代码看了半天。6.2 排查链路从应用到数据库逐层缩小范围我按下面的顺序一步步排查第一步看应用日志。日志里打印的下单时间是正确的18:30:00说明应用代码本身没写错问题出在日志之后的某个环节。第二步看数据库里的原始值。直接在 MySQL 命令行执行SELECT create_time, UNIX_TIMESTAMP(create_time) FROM orders WHERE order_id 12345;发现create_time字段查出来的显示值是18:30:00UNIX_TIMESTAMP(create_time)对应的 UTC 时间戳也正常。这说明数据库服务器层面存入和读取是一致的问题不在存储层。第三步看运营后台读数据的连接。运营后台用的是另一个只读账号我检查它的会话时区SHOW VARIABLES LIKE time_zone;结果这个会话显示的是-05:00。再一查代码原来运营后台的连接池配置里JDBC 连接串写死了serverTimezoneAmerica/New_York而应用主流程的连接串没有指定默认跟随服务器SYSTEM。到这里真相大白数据写入时用的是东八区会话时区存成了正确的 UTC 时间戳运营后台读取时JDBC 告诉驱动的serverTimezone是America/New_York驱动按照北美时区夏令时期间是 UTC-4去解析服务器返回的时间再转成应用 JVM 时区东八区展示于是 18:30 变成了 05:30正好差了 13 个小时。第四步修复。把运营后台的 JDBC 连接串改成和主流程一致的serverTimezoneAsia/Shanghai问题立刻消失。6.3 这次排查留下的三条经验事后复盘有三条经验值得分享第一看到非整小时偏移如 13 小时先别慌它不是简单的服务器时区问题而是多重时区叠加导致的。标准东八区和 UTC 的差异是 8 小时13 小时往往意味着中间还有一层夏令时或其他偏移。第二排查时一定要确认查询端的会话时区而不是只看全局时区。同一个库不同连接可能带不同的time_zone因为会话变量可以独立设置JDBC 也有自己的serverTimezone。第三建立标准的连接串规范和初始化脚本。团队里统一约定MySQL 服务器统一使用08:00或全部 UTCJDBC 连接串一律显式指定serverTimezone不允许依赖环境默认值。这个规范能避免大部分时间问题。7. 与 time_zone 联动的函数行为和使用建议最后再把几个和时间函数相关的知识点串起来顺便给出我在实际项目中推荐的时区使用策略。7.1 NOW、SYSDATE、CURRENT_TIMESTAMP、UTC_TIMESTAMP 的差异这几个函数都返回当前时间但细节上有区别NOW()和CURRENT_TIMESTAMP返回语句开始执行时刻的时间按当前会话时区展示。SYSDATE()返回它本身被执行时刻的时间同样是会话时区但如果一条语句执行时间较长SYSDATE()和NOW()的结果可能有秒级差异。UTC_TIMESTAMP()返回当前的 UTC 时间不受会话时区影响。一个典型例子SET time_zone 08:00; SELECT NOW(), UTC_TIMESTAMP();如果当前 UTC 时间是2024-06-01 10:00:00东八区会话下NOW()返回2024-06-01 18:00:00UTC_TIMESTAMP()返回2024-06-01 10:00:00。UNIX_TIMESTAMP()和FROM_UNIXTIME()也同样依赖会话时区UNIX_TIMESTAMP()把字符串时间按会话时区解释后转成时间戳FROM_UNIXTIME()把时间戳按会话时区转换显示。同一个时间戳在不同会话时区下FROM_UNIXTIME()的结果完全不同。7.2 我推荐的时区使用策略存储固定、展示灵活经过这么多年的实践我的建议是存储层用TIMESTAMP或DATETIME都可以但服务器time_zone和连接串时区必须统一。最稳妥的组合要么是服务器全用 UTCdefault-time-zone 00:00应用层读取后自行转本地时区展示或者服务器全用业务时区国内常用08:00应用层和 JDBC 也统一用Asia/Shanghai不做二次转换。第一种方式对全球化业务更友好所有时间在数据库里都是绝对时间点展示给哪个国家用户再转哪个时区第二种方式对单一时区业务更省心排查问题更直观。我个人的偏好是涉及跨境电商或全球化用 UTC 存只做国内业务直接全链路东八区。千万不要混用。7.3 容易忽略的常见误区清单下面的清单是我在各类项目中反复遇到过的误区你可以对照自查以为修改操作系统时区后MySQL 会自动跟随。实际上需要重启 MySQL。用SET GLOBAL time_zone后当前连接立刻查询发现没变化就放弃。实际上需要新开连接。在my.cnf里写time_zone 08:00。正确写法是default-time-zone。不使用命名时区却写了Asia/Shanghai。若时区表未加载会直接报错。服务器时区、JDBCserverTimezone、JVM 默认时区三处不一致。用DATETIME存业务时间却指望它像TIMESTAMP一样能跨时区自动换算。最后再分享一个小技巧我用 MySQL 的时间问题排查总会先在每个环境跑一条基线查询SELECT GLOBAL.time_zone, SESSION.time_zone, NOW(), UTC_TIMESTAMP(), UNIX_TIMESTAMP();把它作为环境健康检查的一部分。但凡时区相关参数被动过这条查询的结果一眼就会被发现。把这个习惯带进团队能少踩很多坑。 生产环境MySQL时间错乱？彻底搞懂time_zone时区参数
说真的第一次在生产环境踩到 MySQL 时间错乱的时候我整整排查了一个下午。现象非常诡异应用日志里打印的时间是对的写入数据库再查出来却差了 13 个小时换了连接串之后又变成差 8 个小时。后来才发现问题出在 MySQL 时区参数 time_zone 上。这个参数看起来不起眼但它决定了服务器怎么解析时间、怎么给客户端返回时间一旦和操作系统、应用层、连接串各玩各的时间数据就全乱套了。这篇文章我想把 time_zone 这个参数从头到尾讲透它管什么、怎么查怎么设、有哪些坑、怎么排查。不管你是刚入职的新人还是被线上时间问题折磨过的老油条都应该能从中找到自己想要的东西。1. 被时间差逼疯的排查经历time_zone 到底管住了什么先讲个真实案例。我之前帮一个朋友团队看问题他们的业务是电商订单数据库里有一张订单表里面有create_time字段用的是DATETIME类型。某天运营反馈后台看到的订单创建时间和用户下单时间差了 8 个小时。我上去一看应用服务器在东八区数据库服务器也设置了东八区但 MySQL 里SHOW VARIABLES LIKE time_zone;查出来却是SYSTEM然后再查操作系统时区才发现这台数据库服务器的/etc/localtime指向的是UTC。也就是说MySQL 跟着操作系统用了 UTC 时间而应用层是东八区两边各按各的来数据自然对不上。这个案例里有一个关键点time_zone这个参数控制的是 MySQL 服务器端的时间解读方式。它影响三个层面的行为服务器内置时间函数的返回值比如NOW()、CURRENT_TIMESTAMP、CURDATE()。对TIMESTAMP类型字段的读写转换。FROM_UNIXTIME()、UNIX_TIMESTAMP()这类转换函数的结果。很多人会把time_zone和存储时区混为一谈。实际上MySQL 的日期时间类型里只有TIMESTAMP会做时区转换DATETIME完全不做。这两者的差别才是理解 time_zone 行为的第一块敲门砖。1.1 TIMESTAMP 和 DATETIME时区影响的边界在哪里TIMESTAMP的内部存储形式是 UTC 时间戳从1970-01-01 00:00:00 UTC开始算起的秒数。你在东八区写入2024-06-01 12:00:00MySQL 会先把它换算成 UTC 时间也就是2024-06-01 04:00:00存进去等客户端查询时再根据当前会话的time_zone把 UTC 时间换算回本地时间显示。DATETIME就简单粗暴存什么就是什么。你写入2024-06-01 12:00:00查出来还是这个值中间不做任何时区换算。所以你会看到这样的场景一张表里既有TIMESTAMP又有DATETIME如果会话时区从东八区改成 UTCTIMESTAMP字段查出来的值会少 8 个小时而DATETIME字段纹丝不动。这不是数据坏了是类型设计之初就决定的机制。生产环境里大量时间错乱问题的根源都可以归结为写入端的会话时区、查询端的会话时区、以及应用层所理解的时区三者没有统一。要么大家都用东八区要么大家都用 UTC只要有一端不一致TIMESTAMP就会自动帮你换算出一个错误的本地时间。1.2 一次写入和读取时间到底被转换了几次假设你的应用服务器、MySQL 会话时区都是东八区08:00用户在 18:00 下单应用拼接 SQL 写入create_time。如果字段是DATETIME直接存入2024-06-01 18:00:00查询时原样返回全程零转换。如果字段是TIMESTAMPMySQL 把18:00:00理解成东八区时间转成 UTC 存成2024-06-01 10:00:00对应的时间戳查询时再把时间戳换算成08:00的本地时间显示18:00:00。从用户视角看两种类型在大家都用东八区的情况下毫无差别。但一旦会话时区变成09:00TIMESTAMP查出来就会变成19:00:00DATETIME还是18:00:00。这就是我想表达的重点time_zone不是要不要存时区的问题而是MySQL 如何把时间戳和本地时间做双向映射的问题。搞懂了这一层后面所有参数设置和坑就都顺理成章了。2. 三个层级的时区变量global、session、SYSTEM 的读取规则MySQL 的time_zone不是孤零零的一个值它分全局变量和会话变量而且还有一个兜底的 SYSTEM 特殊值。不少人在这上面栽过跟头明明执行了SET GLOBAL time_zone 08:00;当前连接查出来还是老样子就觉得命令没生效。其实不是没生效是没搞懂作用范围。2.1 变量读取顺序session 覆盖 globalglobal 兜底你可以用下面两条命令分别查看全局和当前会话的时区SELECT GLOBAL.time_zone; SELECT SESSION.time_zone;或者用一条命令一次性看两个SELECT GLOBAL.time_zone AS global_tz, SESSION.time_zone AS session_tz;规则很简单新建立的连接会继承全局变量GLOBAL.time_zone作为自己的会话变量SESSION.time_zone但当前连接里如果单独执行过SET time_zone ...就会覆盖继承的值只对这个连接生效。所以当你SET GLOBAL time_zone 08:00;之后已经存在的旧连接不会变只有新连接才会拿到新值。如果你在命令行客户端里执行完全局设置后立刻同一条会话去查询看到的值还是旧的这就是很多人误以为没生效的原因。2.2 改全局却不生效的典型误操作除了作用域问题还有一个权限问题。MySQL 8.0 里设置全局变量需要SYSTEM_VARIABLES_ADMIN权限或更高权限MySQL 5.7 里对应的是SUPER权限。如果你用的是权限受限的业务账号去执行SET GLOBAL time_zone 08:00;会直接报错ERROR 1227 (42000): Access denied; you need (at least one of) the SYSTEM_VARIABLES_ADMIN or SUPER privilege(s) for this operation不少人在这个错误上浪费时间以为语法写错了其实纯粹是账号权限不够换成 root 或者有管理员权限的账号就好。另外SET GLOBAL只在运行期生效数据库一旦重启就会回到配置文件的设置。如果只想临时验证没问题但要长期生效必须把配置写进 MySQL 配置文件具体写法见下一章。2.3 为什么默认值是 SYSTEM 而不是某个固定时区MySQL 的time_zone默认值是SYSTEM意思是跟随 MySQL 所在操作系统的时区设置。MySQL 启动时会读取操作系统的当前时区并缓存起来之后NOW()、TIMESTAMP换算都以这个缓存值为准。这里有一个很隐蔽的坑操作系统时区修改后MySQL 不会自动跟着变。比如你用timedatectl set-timezone Asia/Shanghai改了系统时区正在运行的 MySQL 仍会使用启动时缓存的那个时区必须重启 MySQL 才能让它重新读取。更常见的是 Docker 场景。官方mysql镜像默认的容器内时区是 UTC如果你没有挂载/etc/localtime或者设置TZ环境变量那么容器里的 MySQL 的time_zone就是SYSTEMSYSTEM 对应的又是 UTC。你在宿主机看起来是东八区容器里却按 UTC 走时间自然差 8 个小时。提示开机后第一件事先跑一遍SELECT GLOBAL.time_zone, SESSION.time_zone;再确认一下操作系统的date %Z把这两层关系看清楚能省掉后面 80% 的排查时间。3. time_zone 的设置方式会话、全局、配置文件各有各的坑设置time_zone的方式大致有三种会话级、全局级、配置文件持久化。它们适用场景不一样坑也不一样。我按我平时的工作习惯逐个讲。3.1 会话级设置临时改随连随走只想让当前连接临时换一个时区直接执行SET time_zone 08:00; -- 等价于 SET SESSION time_zone 08:00;SET time_zone ...默认就是设置会话变量不需要额外加SESSION关键字。它的生效范围是当前连接连接关闭就还原。适合在跑某些一次性脚本时想让NOW()或TIMESTAMP输出符合某个时区又不想影响别人的场景。比如在数据订正脚本里你想把只读库里的TIMESTAMP字段按东八区导出来先执行SET time_zone 08:00;再SELECT结果就会按东八区展示了。3.2 全局级设置在线生效重启丢失全局设置用GLOBAL关键字SET GLOBAL time_zone 08:00;它会让之后新建的连接使用新时区正在运行的连接不受影响。想验证有没有生效新开一个连接再查SELECT GLOBAL.time_zone, SESSION.time_zone;全局设置的优点是零停机、不用重启服务适合在排查时间问题时快速做线上验证。缺点是重启后失效必须配合配置文件持久化。3.3 配置文件持久化default-time-zone 才是正解这是我觉得最值得强调的一个点在 MySQL 配置文件my.cnf或my.ini里用于设置时区的选项名是default-time-zone不是time_zone。正确的写法是在[mysqld]段下[mysqld] default-time-zone 08:00如果你写成[mysqld] time_zone 08:00就可能遇到两种情况MySQL 启动时直接报错具体取决于版本对未知选项的解析方式或者配置被忽略重启后时区还原。很多人把配置写进去后重启发现time_zone没变第一反应是重启没生效其实很可能就是整个选项名写错了。如果你用命令行方式启动 mysqld对应参数是mysqld --default-time-zone08:00 --socket/tmp/mysql.sock另外要注意如果服务器上部署了多个 MySQL 实例每个实例都有自己的配置文件别改错文件。用下面的命令可以确认实际加载的配置文件路径mysqld --verbose --help 2/dev/null | grep -A 1 Default options配置文件修改完之后需要重启 MySQL 才能让所有连接统一拿到新时区。所以我的建议是先用SET GLOBAL验证业务影响确认无误后再写配置文件做持久化最后选低峰期重启一次做兜底。3.4 偏移量写法和命名时区的区别设置time_zone时值可以是固定偏移量也可以是命名时区-- 固定偏移量 SET time_zone 08:00; SET time_zone -05:30; -- 命名时区依赖时区表 SET time_zone Asia/Shanghai; SET time_zone America/New_York;固定偏移量写法不依赖任何额外数据表MySQL 直接按给定偏移量转换简单直接适合国内绝大多数只使用东八区的业务。命名时区如果要生效前提是 MySQL 的时区表mysql.time_zone*系列表已经加载了数据否则会报错ERROR 1298 (HY000): Unknown or incorrect time zone: Asia/Shanghai这一块内容比较深单独开一节讲。4. 命名时区与时区表平时用不到一踩就是大坑很多从没接触过时区表的人会问为什么我在配置文件里写了default-time-zone Asia/ShanghaiMySQL 就启动不了了为什么执行SET time_zone Asia/Shanghai会报Unknown or incorrect time zone答案很简单MySQL 默认安装并不会加载操作系统时区数据。你看到mysql.time_zone_name表是空的或者整个库里根本没有相关表数据Asia/Shanghai这样的名字自然无法识别。4.1 用 mysql_tzinfo_to_sql 加载时区数据标准做法是使用 MySQL 自带的mysql_tzinfo_to_sql工具把操作系统的时区数据导入 MySQLmysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql导入后可以验证一下SELECT COUNT(*) FROM mysql.time_zone; SELECT * FROM mysql.time_zone_name WHERE Name Asia/Shanghai;正常情况下mysql.time_zone里有几百条时区记录。之后就可以正常使用SET time_zone Asia/Shanghai;或者在配置文件中写[mysqld] default-time-zone Asia/Shanghai要注意的是操作系统/usr/share/zoneinfo目录的时区数据如果很旧可能导致导入的夏令时规则过时。生产环境建议在操作系统层面保持更新再重新导入一次。4.2 偏移量写法和命名时区的本质差异固定偏移量08:00是死的它只代表一个固定的时间偏移不存在夏令时概念。命名时区Asia/Shanghai是活的它包含该地区的历史和当前时区规则MySQL 会按照规则表自动处理夏令时切换。中国从 1991 年之后就不再实行夏令时所以Asia/Shanghai实际上常年等价于08:00。但对涉及美国、欧洲业务的系统来说America/New_York、Europe/London这类命名时区会随夏令时切换而改变偏移这才是命名时区真正的价值所在。4.3 夏令时切换的真实影响举一个具体例子美国 2024 年夏令时从 3 月第二个周日凌晨 2:00 开始时钟拨到 3:00也就是说02:00:00到02:59:59这一个小时在当天是不存在的。如果你把time_zone设置为America/New_York并且业务涉及这个时间段写入的TIMESTAMP数据就会遇到比较棘手的情况这个小时的本地时间无法映射到真实 UTC 时间MySQL 的处理方式可能与你预期不同可能导致数据在夏令时切换那一刻出现异常展示。反过来说春季切换时虽然少了一个小时但多出来的重复小时也有问题秋季切换那天01:00:00到01:59:59会经历两次。同一个本地时间对应两个不同的 UTC 时刻TIMESTAMP换算时会因为会话时区设置的不同产生两套结果。我接触过的一些跨境电商团队为了避免这类问题直接在数据库层使用00:00或08:00固定偏移把夏令时逻辑完全交给上层应用处理。这种做法牺牲了数据库层面的可读性但换来了确定性对交易类系统来说往往更稳妥。提示如果业务不跨夏令时地区强烈建议直接用固定偏移量。不是命名时区不好而是多一层时区规则就会多一层不可控风险尤其当上游时区数据源没有及时更新的时候。5. 连接层的二次时区JDBC、客户端工具为什么总跟你作对很多人会忽略一个事实time_zone是 MySQL 服务器端的参数但你的应用不一定只和服务器打交道。JDBC 驱动、ORM 框架、数据库客户端工具都有自己的时区处理逻辑。服务器端时区设置正确了连接层如果没跟上照样出乱子。5.1 经典报错serverTimezone 参数与 MySQL time_zone 的关系用 JDBC 连接 MySQL 时最经典的报错长这样java.sql.SQLException: The server time zone value Öйú±ê׼ʱ¼ä is unrecognized or represents more than one time zone.这个报错里那段乱码实际上是 GBK 编码的中国标准时间在客户端被错误解码后的样子。MySQL 服务器返回了操作系统层面的时区描述而 Connector/J 无法识别。解决办法是在 JDBC URL 中显式指定serverTimezonejdbc:mysql://localhost:3306/dbname?serverTimezoneAsia/ShanghaiuseSSLfalse也可以写成 GMT 偏移量jdbc:mysql://localhost:3306/dbname?serverTimezoneGMT%2B8注意 URL 里号需要编码成%2B否则可能被解析成空格导致时区设置无效。serverTimezone参数的本质是告诉 JDBC 驱动MySQL 服务器当前使用的是什么时区。 驱动拿到这个值后会在应用 JVM 时区与 MySQL 时区之间做一次转换。如果你把serverTimezoneAsia/Shanghai写死但 MySQL 服务器本身是 UTC那么 JDBC 会在两边之间强行加一道换算结果就是应用读到的时间整体偏移。我见过不止一次这样的场景团队把serverTimezone设置成Asia/Shanghai又觉得不放心额外给 MySQL 也设置了08:00结果两边一致数据正常后来有人把 MySQL 全局时区调成了00:00但 JDBC 连接串没改第二天全线时间差了 8 个小时。把这个连接串参数和服务器参数视为同一个系统的两个半场非常关键。5.2 客户端工具和 ORM 的干扰因素不只是 JDBC。Navicat、DBeaver、DataGrip 这类图形化客户端默认也会按照本机的时区来显示TIMESTAMP类型的值。你在服务器上执行SELECT NOW();得到一个时间客户端工具里看到的时间可能不一样因为工具本身又做了一层转换。ORM 层面也常有干扰。Hibernate、MyBatis 等框架一般不会主动改时区但如果应用的 JVM 默认时区不是东八区java.util.Date在序列化和反序列化时就会产生偏差。排查时一定要把 JVM 时区也纳进来java -XX:PrintFlagsFinal -version | grep -i timezone正常地排查链路应该是操作系统时区 → MySQL 全局/会话时区 → JDBCserverTimezone→ 应用 JVM 时区四层保持一致才能保证TIMESTAMP从写入到读取一路无偏移。6. 一次线上时间错乱问题的完整排查过程前面讲了不少原理这一节我把一次完整的线上排查过程原原本本写出来方便你照着这个思路去套自己的场景。6.1 现象用户下单时间比实际提前了 13 小时当时业务反馈运营后台看到的订单创建时间是2024-05-20 05:30:00实际下单时间是当天18:30:00差了 13 个小时。13 个小时这个数字很有迷惑性不是标准的 8 小时所以一开始大家都以为是数据问题对着 SQL 和代码看了半天。6.2 排查链路从应用到数据库逐层缩小范围我按下面的顺序一步步排查第一步看应用日志。日志里打印的下单时间是正确的18:30:00说明应用代码本身没写错问题出在日志之后的某个环节。第二步看数据库里的原始值。直接在 MySQL 命令行执行SELECT create_time, UNIX_TIMESTAMP(create_time) FROM orders WHERE order_id 12345;发现create_time字段查出来的显示值是18:30:00UNIX_TIMESTAMP(create_time)对应的 UTC 时间戳也正常。这说明数据库服务器层面存入和读取是一致的问题不在存储层。第三步看运营后台读数据的连接。运营后台用的是另一个只读账号我检查它的会话时区SHOW VARIABLES LIKE time_zone;结果这个会话显示的是-05:00。再一查代码原来运营后台的连接池配置里JDBC 连接串写死了serverTimezoneAmerica/New_York而应用主流程的连接串没有指定默认跟随服务器SYSTEM。到这里真相大白数据写入时用的是东八区会话时区存成了正确的 UTC 时间戳运营后台读取时JDBC 告诉驱动的serverTimezone是America/New_York驱动按照北美时区夏令时期间是 UTC-4去解析服务器返回的时间再转成应用 JVM 时区东八区展示于是 18:30 变成了 05:30正好差了 13 个小时。第四步修复。把运营后台的 JDBC 连接串改成和主流程一致的serverTimezoneAsia/Shanghai问题立刻消失。6.3 这次排查留下的三条经验事后复盘有三条经验值得分享第一看到非整小时偏移如 13 小时先别慌它不是简单的服务器时区问题而是多重时区叠加导致的。标准东八区和 UTC 的差异是 8 小时13 小时往往意味着中间还有一层夏令时或其他偏移。第二排查时一定要确认查询端的会话时区而不是只看全局时区。同一个库不同连接可能带不同的time_zone因为会话变量可以独立设置JDBC 也有自己的serverTimezone。第三建立标准的连接串规范和初始化脚本。团队里统一约定MySQL 服务器统一使用08:00或全部 UTCJDBC 连接串一律显式指定serverTimezone不允许依赖环境默认值。这个规范能避免大部分时间问题。7. 与 time_zone 联动的函数行为和使用建议最后再把几个和时间函数相关的知识点串起来顺便给出我在实际项目中推荐的时区使用策略。7.1 NOW、SYSDATE、CURRENT_TIMESTAMP、UTC_TIMESTAMP 的差异这几个函数都返回当前时间但细节上有区别NOW()和CURRENT_TIMESTAMP返回语句开始执行时刻的时间按当前会话时区展示。SYSDATE()返回它本身被执行时刻的时间同样是会话时区但如果一条语句执行时间较长SYSDATE()和NOW()的结果可能有秒级差异。UTC_TIMESTAMP()返回当前的 UTC 时间不受会话时区影响。一个典型例子SET time_zone 08:00; SELECT NOW(), UTC_TIMESTAMP();如果当前 UTC 时间是2024-06-01 10:00:00东八区会话下NOW()返回2024-06-01 18:00:00UTC_TIMESTAMP()返回2024-06-01 10:00:00。UNIX_TIMESTAMP()和FROM_UNIXTIME()也同样依赖会话时区UNIX_TIMESTAMP()把字符串时间按会话时区解释后转成时间戳FROM_UNIXTIME()把时间戳按会话时区转换显示。同一个时间戳在不同会话时区下FROM_UNIXTIME()的结果完全不同。7.2 我推荐的时区使用策略存储固定、展示灵活经过这么多年的实践我的建议是存储层用TIMESTAMP或DATETIME都可以但服务器time_zone和连接串时区必须统一。最稳妥的组合要么是服务器全用 UTCdefault-time-zone 00:00应用层读取后自行转本地时区展示或者服务器全用业务时区国内常用08:00应用层和 JDBC 也统一用Asia/Shanghai不做二次转换。第一种方式对全球化业务更友好所有时间在数据库里都是绝对时间点展示给哪个国家用户再转哪个时区第二种方式对单一时区业务更省心排查问题更直观。我个人的偏好是涉及跨境电商或全球化用 UTC 存只做国内业务直接全链路东八区。千万不要混用。7.3 容易忽略的常见误区清单下面的清单是我在各类项目中反复遇到过的误区你可以对照自查以为修改操作系统时区后MySQL 会自动跟随。实际上需要重启 MySQL。用SET GLOBAL time_zone后当前连接立刻查询发现没变化就放弃。实际上需要新开连接。在my.cnf里写time_zone 08:00。正确写法是default-time-zone。不使用命名时区却写了Asia/Shanghai。若时区表未加载会直接报错。服务器时区、JDBCserverTimezone、JVM 默认时区三处不一致。用DATETIME存业务时间却指望它像TIMESTAMP一样能跨时区自动换算。最后再分享一个小技巧我用 MySQL 的时间问题排查总会先在每个环境跑一条基线查询SELECT GLOBAL.time_zone, SESSION.time_zone, NOW(), UTC_TIMESTAMP(), UNIX_TIMESTAMP();把它作为环境健康检查的一部分。但凡时区相关参数被动过这条查询的结果一眼就会被发现。把这个习惯带进团队能少踩很多坑。