故障复盘-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’可解决,修此参数流量回

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

shaohjz

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值