MySQL active threads more than 40 on db3.***.com

最近db机器老是出现MySQL active threads more than 40的报警，同时也有cpu load too high的报警，当时怀疑是db在备份的同时又压缩加上数据量越来越多，造成db负载增大所致，后来就将mysqldump和gzip 分两步来做，这样肯定会某种程度上有所减轻，其实如果备份机器上、上有足够的空间来存放mysqldumpm产生的sql ，gzip(gzip在备份机上执行，这样就会节省生产机上的资源，降低生产机的负载)时产生的sql是可以的，但备份机器的空间太小，不能这样来做，所以不得已，将mysqldump和gzip分成两步来做，而且后来发现cpu load too high 的报警，没有规律，并非发生在db 备份的时间段，于是去查看了最近18天的cpu load的图形，发现最近14天来，cpu load 明显有所上升(这个报警有一段时间了，只是不影响业务，没太着急处理)，于是怀疑sql或数据量的增多所致，在监控db时发现，就算没有备份，在某几个sql执行的时候，w显示机器的负载明显增大（5左右），显然是sql有问题，于是用pt-query-digest工具分析慢查询，发慢查询分析结果给研发，我自己在explain sql的时候也发现，根本没有使用索引，这样在大数据量查询的时候，速度可想而知，sql的获取是通过show  full  processlist获取的。Sql修改后，查看cpu load趋势发现，cpu load 有所下降，同时cpu load too high  too many thread的报警也消失了

修改sql前后的对比：