客户问题
发现CPU监控断点，大约持续6~7分钟，期间业务不可访问
CPU监控断点分析定位
我们从实例监控图可以看出
实例监控图- CPU使用率从中断到超出100%
- threads_connected和threads_running飙升
- 慢查询也有突增
其中有些是现象，有些是原因，线程数增高的原因是什么，很明显是某些语句阻塞了后续的请求，导致请求堆积，连接线程数和运行线程数突增，导致CPU利用率飙升，进而导致监控上报agent异常，当这个罪魁祸首SQL执行完毕之后，后续请求会得到顺畅执行，实例状态会恢复
问题解决
问题已经分析出来了，就是某个SQL阻塞了其他请求，那么如何找到这条SQL呢？有两种方式
- 抓现场，故障时间点执行
show processlist,观察下当前SQL会话的情况，并且select * from information_schema.innodb_trx; - 事后查日志，从上面监控图可以看出本次罪魁祸首SQL执行完毕的时刻，记录了大量慢查询，那么我们大胆推测，一定有一个SQL锁表时长约在6~7分钟，我们从慢日志中找出即可
由于本次是事后分析，因此采用查慢日志的方式
慢日志从上图可以看出，查询时间411s的语句就是锁表的语句，是本次监控断点的原因
tips:大量prepare的原因是因为同一时刻执行了大量其他SQL，由于和长时间执行的那条SQL存在冲突，导致只记录了prepare状态，SQL并未执行
image.png
规避措施
优化慢SQL，解决锁冲突
