mysql TMM_MySQL：timestamp时区转换导致CPU %sy高的问题

一、问题展示

下面是问题当时的系统负载如下：

image.png

我们可以看到40.4%sy 正是系统调用负载较高的表现，随即朋友采集了perf如下：

image.png

接下来朋友采集了pstack给我，我发现大量的线程处于如下状态下：

我们可以注意一下__tz_convert 这正是时区转换的证据。

二、关于timestamp简要说明

timestamp：占用4字节，内部实现是新纪元时间(1970-01-01 00:00:00)以来的秒，那么这种格式在展示给用户的时候就需要做必要的时区转换才能得到正确数据。下面我们通过访问ibd文件来查看一下内部表示方法，使用到了我的两个工具innodb和bcview，详细参考https://www.jianshu.com/p/719f1bbb21e8。

timestamp的内部表示

建立一个测试表

我们来查看一下内部表示如下：

整理一下如下：

000001ac3502：rowid

000000070d52：trx id

c80000002f0110：roll ptr

5c2a4b4d：timestamp类型的实际数据十进制为1546275661

我们使用Linux命令如下：

因为我的Linux也是CST +8时区这里数据也和MySQL中显示一样。下面我们调整一下时区再来看看取值如下：

这里可以看到减去了2个小时，因为我的时区从+8变为了+6。

三、timestap转换

在进行新纪元时间(1970-01-01 00:00:00)以来的秒到实际时间之间转换的时候MySQL根据参数time_zone的设置有两种选择：

time_zone：设置为SYSTEM的话，使用sys_time_zone获取的OS会话时区，同时使用OS API进行转换。对应转换函数 Time_zone_system::gmt_sec_to_TIME

time_zone：设置为实际的时区的话，比如‘+08:00’，那么使用使用MySQL自己的方法进行转换。对应转换函数 Time_zone_offset::gmt_sec_to_TIME

实际上Time_zone_system和Time_zone_offset均继承于Time_zone类，并且实现了Time_zone类的虚函数进行了重写，因此上层调用都是Time_zone::gmt_sec_to_TIME。

注意这种转换操作是每行符合条件的数据都需要转换的。

四、问题修复方案

我们从问题栈帧来看这个故障使用的是 Time_zone_system::gmt_sec_to_TIME 函数进行转换的，因此可以考虑如下：

time_zone：设置为指定的时区，比如‘+08:00’。这样就不会使用OS API进行转换了，而转为MySQL自己的内部实现 调用 Time_zone_offset::gmt_sec_to_TIME函数。但是需要注意的是，如果使用MySQL自己的实现那么us%会加剧。

使用datetime代替timestamp，新版本datetime为5个字节，只比timestamp多一个字节。