最近电视剧《狂飙》大火，我也是欲罢不能。然后就想到大家在使用MySQL过程，想必都有遇到过CPU突然狂飙过高，或者达到%以上的情况。
数据库执行查询或数据修改操作时，系统需要消耗大量的CPU资源维护存储系统、内存数据中的一致性。
并发量大并且大量SQL性能低的情况下，比如字段没有建立索引，则会导致快速CPU飙升，如果还开启了慢日志记录，会导致性能更加恶化。生产上有MYSQL飙升%的恶劣情况。
一、MySQL进程CPU飙升到%，怎么处理？1、定位过程
使用top命令观察，确定是mysqld导致还是其他原因；如果是mysqld导致的，showprocesslist，查看session情况，确定是不是有消耗资源的sql在运行；找出消耗高的sql，看看执行计划是否准确，index是否缺失，或者实在是数据量太大造成；2、处理过程
kill掉这些线程(同时观察cpu使用率是否下降)，一般来说，肯定要kill掉这些线程(同时观察cpu使用率是否下降)，等进行相应的调整(比如说加索引、改sql、改内存参数)之后，再重新跑这些SQL；进行相应的调整(比如说加索引、改sql、改内存参数)；index是否缺失，如果是，则建立索引。也有可能是每个sql消耗资源并不多，但是突然之间，有大量的session连进来导致cpu飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等；优化的过程，往往不是一步完成的，而是一步一步，执行一项优化措辞，再观察，再优化；二、MySQL数据库优化的真实案例之前开发朋友编写的SQL语句，就导致过线上CPU过高，MySQL的CPU使用率达到%，通过优化最后降低到70%~80%。下面说说个人在这个过程中的排查思路。
首先，我们要对问题定位而不是盲目的开启什么慢日志，在并发量大并且大量SQL性能低的情况下，开启慢日志无疑是将MySQL推向崩溃的边缘。
当时遇到这个情况，分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大，也就几百万条而已。接下来就去定位索引、缓存问题。
1、经过询问，发现很多查询都是走MySQL，没有用到缓存。
2、既然没有用到缓存，则是大量请求全部查询MySQL导致。
通过下面的命令查看:
发现类似很多相同的SQL语句，一直处于query状态中。
初步分析可能是name字段没有索引导致。接着查询worker表的索引情况：
发现这个字段是没有建立索引。增加索引之后，该条SQL查询能够正常执行。
、每隔一会，又发生大量的请求超时问题。接着进行分析，发现是开启了慢日志查询。大量的SQL查询语句超过慢日志设置的阀值，于是将慢日志关闭之后，速度瞬间提升。CPU的使用率基本保持在00%左右。但还不是理想状态。
4、紧接着将部分实时查询数据的SQL语句，都通过缓存(redis)读写实现。观察一段时间后，基本维持在了70%~80%。
三、总结其实本次事故的解决很简单，就是添加索引与缓存结合使用。
不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低；直接通过MySQLshowprocesslist命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，再针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致；再则一定要使用缓存系统，降低对MySQL的查询频次；对于内存调优，也是一种解决方案；