Why
Case 1—> 慢sql
大多数的cpu过高都是由慢sql导致的，尤其是涉及到计算函数之类的，例如全表扫描或者说数据量过大，
内存排序 && 磁盘排序 以及 锁竞争等待…
那我们看到的又是什么呢？
以下截图来自百度~
此时CPU上升
QPS趋于稳定甚至有下降趋势
这类问题归功于慢sql导致的，可采取kill+id的方法先杀掉
我们通过 show processlist 可以看到当前正在执行的sql状态为
Sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，Using filesort，Locked;
Noted: 上述命令（show processlist）只能看到当前执行的sql对应进程，大半夜的又该怎么办呢？RDS
还是非常友好的，左侧菜单栏可以配置慢sql报警，对应的慢sql，连接的user等信息可以尽收眼底，回头
一一干掉，对了你也可以开通阿里云的sql审计功能，所有sql都会记录，但是！收费哈哈！
Case 2 —> QPS
观察CPU曲线利用率达到100
恰巧QPS对应的曲线利用率也是100
观察慢sql曲线，发现并不存在
总结：如遇以上情况，可以归功于QPS过高导致的，如有开通审计功能，可以查看最近一个月的QPS记录，找到对应的机器，对sql调用量进行top，如未开通，只好考虑对慢sql监控，进行报警，最终定位接口进行处理。
How
Case 1—> 慢sql
如果您的线上环境sql出现以上sql状态，说明sql性能有问题
Sending data： 正在执行sql查询，数据量过大或者说全表扫描了，没有建立索引，或者说索引建立
的不合适，索引失效等情况导致的sql查询时间过长。可以先看下该sql 执行计划 便后处理
Copying to tmp table on disk 像这种的状态一般都是sql查询的临时结果集过大，超过了数据库约
束的临时数据内存大小，需要将这个临时结果集拷贝到磁盘，无非就是sql查询范围过大或者sql查询时间
过长。
Sorting result，Using filesort： 对sql结果进行排序会产生高额的cpu消耗，多数情况下还是会借助
建立合适的索引消除排序或者减小排序结果集。
总而言之，言而总之，奇妙的事情诞生了，都是由于性能不高（慢sql）导致，处理线上慢sql，写好sql
是关键，sql优化老生常聊，大家也都知道，后续会为大家分享索引失效的篇章！
