客户现场反馈,top的检查结果中,一个CPU的占用一直是100%。实际上现场有4个CPU,并且这个服务器是mysql专属服务器。java
个人第一反应是io_thread一类的参数设置有问题,检查之后发现read和write的thread设置都是4,这和CPU数一致,所以能够判定这并非单颗CPU占用太高的问题。mysql
接下来须要确认MySQL究竟有没有利用到多核CPU,这个时候须要的工具叫作pidstat,命令以下:sql
pidstat -u -t -p 18158
获得的结果以下图所示:bash
能够看出其实mysqld是能够利用到多核CPU的,那么此时能够获得一个推断:服务器
某个CPU上作的事情太占资源了运维
通常这种最占资源的工做必定会在INNODB_TRX里留下一些端倪,所以检查一下:工具
反复的检查TRX,发现mysql在不停的执行这个SQL,只是where条件里的值发生了变化,至此我能够推断出业务应该是写了一个循环来遍历一个list,而后对每一个item都执行update操做。3d
应该是写了这么一段代码在处理问题:code
for (item in list) { update_db(item); }
检查这个表并无索引,给where条件中的列加上索引,再次检查CPU的占用,发现如今的占用已经下降到了16%左右,虽然仍是很高,可是已经实际上解决了该问题。blog
这里我有点感慨,DBA并非你会写SQL就能够干的,DBA其实是运维人员的一种,运维要掌握多少种技能恐怕只有运维小伙伴们清楚,其实技术难度并不比写Java 代码低。DBA掌握多少种检查问题的手段,DBA面对问题时能不能第一时间找准方向,这都是经验和功力的展示。