MySQL CPU 飙升到 900%+数据库优化的真实案例

陈某提示：以下案例，来自互联网。大家参考一下，准备一个自己的案例。

本问题亲身经历过。

之前开发同事编写的SQL语句，就导致过线上CPU过高，MySQL的CPU使用率达到900%+，通过优化最后降低到70%~80%。下面说说个人在这个过程中的排查思路。

首先，我们要对问题定位而不是盲目的开启什么慢日志，在并发量大并且大量SQL性能低的情况下，开启慢日志无意是将MySQL推向崩溃的边缘。

当时遇到这个情况，分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大，也就几百万条而已。接下来就去定位索引、缓存问题。

show processlist;

发现类似很多相同的SQL语句，一直处于query状态中。

select id form user where user_code = 'xxxxx';

初步分析可能是 user_code 字段没有索引导致。接着查询user表的索引情况：

show index form user;

发现这个字段是没有建立索引。增加索引之后，该条SQL查询能够正常执行。

3、没隔一会，又发生大量的请求超时问题。接着进行分析，发现是开启了慢日志查询。大量的SQL查询语句超过慢日志设置的阀值，于是将慢日志关闭之后，速度瞬间提升。CPU的使用率基本保持在300%左右。但还不是理想状态。

4、紧接着将部分实时查询数据的SQL语句，都通过缓存(redis)读写实现。观察一段时间后，基本维持在了70%~80%。

总结：其实本次事故的解决很简单，就是添加索引与缓存结合使用。

不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求，如果真是慢日志问题会发生日志磁盘写入，性能贼低。
直接通过MySQL show processlist命令查看，基本能清晰的定位出部分查询问题严重的SQL语句，在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。
再则一定要使用缓存系统，降低对MySQL的查询频次。
对于内存调优，也是一种解决方案。