错误使用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’可解决,修此参数流量回