经常听见用户说自己的rds实例cpu超过100%，通常这种情况都是由于sql性能问题导致的,下面我用一则案例来分析：

   用户实例zuowenwang反映cpu超过100%，实例偶尔出现卡住的现象；

   1.原理：cpu消耗过大通常情况下都是有慢sql造成的，这里的慢sql包括全表扫描，扫描数据量过大，内存排序，磁盘排序，锁争用等待等；

   2.表现现象sql执行状态为：sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result，locked;

   3.解决方法：用户可以登录到rds，通过show processlist查看当前正在执行的sql，当执行完show processlist后出现大量的语句，通常其状态出现sending data，Copying to tmp table，Copying to tmp table on disk，Sorting result, Using filesort 都是sql有性能问题；

   A.sending data表示：sql正在从表中查询数据，如果查询条件没有适当的索引，则会导致sql执行时间过长；

   B.Copying to tmp table on disk：出现这种状态，通常情况下是由于临时结果集太大，超过了数据库规定的临时内存大小，需要拷贝临时结果集到磁盘上，这个时候需要用户对sql进行优化；

   C.Sorting result, Using filesort：出现这种状态，表示sql正在执行排序操作，排序操作都会引起较多的cpu消耗，通常的优化方法会添加适当的索引来消除排序，或者缩小排序的结果集；

   通过show processlist发现如下sql：

   性能sql：

   用explain 查看执行计划：

   添加适当索引消除排序：

   这种sql order by rand()同样也会出现排序;

   这种随机抽取一批记录的做法性能是很差的，表中的数据量越大，性能就越差：

   解决方法如下：

   第一种方案，即原始的 Order By Rand() 方法：

   3万条数据查12条随机记录，需要0.125秒，随着数据量的增大，效率越来越低。

   第二种方案，改进后的 JOIN 方法：

   3万条数据查12条随机记录，需要0.004秒，效率大幅提升，比第一种方案提升了约30倍。缺点：多次select查询，IO开销大。

   第三种方案，SQL语句先随机好ID序列，用 IN 查询(飘易推荐这个用法，IO开销小，速度最快)：

   3万条数据查12条随机记录，需要0.001秒，效率比第二种方法又提升了4倍左右，比第一种方法提升120倍。注，这里使用了 order by field($idlist2) 是为了不排序，否则 IN 是自动会排序的。缺点：有可能遇到ID被删除的情况，所以需要多选几个ID。

   C．出现sending data的情况：

   性能sql：

   这种sql是典型的sql分页写法不规范的情况，需要将sql进行改写：

   注意这里的索引需要改用覆盖索引：aid+ subject+description

   优化后的结果：

   总结：

      Sql优化是性能优化的最后一步，虽然位于塔顶，他最直影响用户的使用，但也是最容易优化的步骤，往往效果最直接。

      RDS-mysql由于有资源的隔离，不同的实例规格拥有的iops能力不同，比如新1型提供的iops为150个，也就是每秒能够提供150次的随机磁盘io操作，所以如果用户的数据量很大，内存很小，由于iops的限制，一条慢sql就很有可能消耗掉所有的io资源，而影响其他的sql查询，对于数据库来说就是所有的sql需要执行很长的时间才能返回结果，对于应用来说就会造成整体响应的变慢；所以优化永不止境，既可以帮助你的系统稳定，同时又可以节约你的成本，何乐不为。

--转自