[转帖]time_zone 是怎么打爆你的MySQL的

https://plantegg.github.io/2023/10/03/time_zone%E6%98%AF%E6%80%8E%E4%B9%88%E6%89%93%E7%88%86%E4%BD%A0%E7%9A%84MySQL%E7%9A%84/

基础知识

这篇关于time_zone 的总结写得非常好Time_zone ，建议先读完做个基础知识的打底

问题

一般MySQL都会设置 time_zone 为 system，方便MySQL部署在不同的国家、时区也都能很好兼容，这是很符合逻辑的设置。

如果我们的查询中有一个列类型是 timestamp 的话，意味着：

timestamp 数据类型会存储当时 session的时区信息，读取时会根据当前 session 的时区进行转换；而 datetime 数据类型插入的是什么值，再读取就是什么值，不受时区影响。也可以理解为已经存储的数据是不会变的，只是 timestamp 类型数据在读取时会根据时区转换

如果MySQL 读取 timestamp 字段时，需要做时区转换，当 time_zone 设置为 system 时，意味着MySQL 要去follow OS系统时区，也就是把读到的timestamp 根据OS系统时区进行转换，这个转换调用OS 的glibc 的时区函数来获取 Linux OS 的时区，在这个函数中会加 mutex 锁，当并发高时，会出现 mutex 竞争激烈，每次只有一个线程获得锁，释放锁时会唤醒所有等锁线程，但最终只有一个能获取，于是一下子导致系统 sys飙高、上下文切换飙高。每读取一行带 timestamp 字段时，都会通过这个 glibc 的时区函数导致锁竞争特别激烈最终 QPS 拉胯厉害。

想一想，你一个SQL查1万行，10个并发这点流量其实一点都不过分，但是这里需要10*1万次转换，锁争抢就激烈了。

分析参考这个： https://opensource.actionsky.com/20191112-mysql/

perf 以及火焰图如下：

解决

在中国可以将 time_zone=’+8:00’ 将 time_zone 固定死，不再需要follow OS 时区，所以也不需要调用glibc 获取系统时区，避免了前面所说的锁竞争

这个经验来自无数次线上故障复盘，因为 time_zone 设置为 system 是个默认行为，所以要全部改过来还真不容易，给了我们就业机会 :)

当然学习总是希望交叉起来，既有深度又有宽度你才能掌握更好，所以请趁热打铁：

进一步学习

东八区CST 被JDBC 驱动错误识别成了美国的中央时间，官方修复