故障复盘-MySQL的time_zone未正确配置导致现网CPU飙升

错误使用TIMESTAMP导致数据库CPU飙升

现网现象​

业务请求量和扫描行数并没有增加多少，但出现cpu打死业务阻塞了，平时执行1s左右的sql，突然慢到需要执行10多s，大量的慢导致数据库卡死

排查与分析

通过记录的快照发现是该语句导致

 SELECT * FROM `[业务表A ] WHERE (`createTime` > '2024-08-27 16:02:39' and `status` = 'initial' and `nextRuntime` <= 1727337759) LIMIT 200

通过审计日志分析头一天的请求和扫描行数，这个请求并没有增加多少和数量也都持平相差不多，业务也没有发版变更，突然这个语句就变慢了，怀疑是命中了mysql性能问题导致

临时处理

1.对该接口进行限频
2.重启业务进程

问题复现

msyql分析此类问题提供了流量回放功能，DBA帮助我们通过克隆对应时间范围的实例数据，然后回放流量，问题复现了

分析mysql执行计划，发现正常和慢时并没有索引跑偏，数据扫描行数也没有变化，通过开mysql执行详情慢在了sending data处理，即读取数据发给客户端环节

通过打堆栈看函数调用，发现了__lll_lock_wait_private调用高，在网上找到类式说明(https://nereuschen.github.io/2017/07/12/MySQL-CPU-sys%E9%A3%99%E9%AB%98/)，即时缀转换为时间消耗导致

结论

表中的时间字段createTime为timestamp，在查询中需转换为datetime，由于查询条件索引不优扫描过多cpu消耗过多导致，通过修改time_zone=SYSTEM改为time_zone='+8:00’可解决，修此参数流量回