mysql cpu占用高问题排查

连接数：连接数严重超过参考值，并且有过多的空闲线程。首先检查应用是否使用连接池，如果使用连接池，检查连接池的配置是否合理。

系统执行应用提交查询（包括数据修改操作）时需要大量的逻 辑读，（逻辑 IO，执行查询所需访问的表的数据行数），需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。造成逻辑读高的原因，很可能是异常SQL，扫描的数据行数过多导致。

QPS比较高，每秒SQL的语句执行次数高，业务量上来，处于业务的高峰期，用户连接数增加，访问量增加。

如果QPS比较高，逻辑读不高，慢SQL也不是系统的瓶颈，QPS和cpu使用率的变化曲线吻合，这时候优化的余地就不高了，可以从实例规格、应用架构方面进行考虑。

如果QPS不高，查询执行效率低、执行时需要扫描大量表中数据、优化余地大，并且出现慢查询问题，QPS和CPU的变化曲线不吻合

如果QPS比较高，并且逻辑读也比较高，CPU的使用率增加，这时候可以优化优化相应的慢SQL，添加主实例的只读实例来缓解压力。

全表扫描次数：随着业务量的增加，全表扫描的次数也随之增加。Sql要尽量避免全表扫描

如果IOPS比较高的话，有可能是以下原因：

1、实例内存满足不了缓存数据或排序等需要，导致产生大量的物理 IO。

2、查询执行效率低，扫描过多数据行。

解决方法：

1、查询是否有慢SQL，优化慢SQL，可以参考杜康的实例卡慢诊断的优化建议，或者登录DMS，通过诊断报告、优化来进行SQL优化

2、终止查询语句

3、通过show processlist，或者DMS控制台、杜康等来kill查询回话id

c)         MySQL内存使用率：基本上是一条直线，没有变化。因为MySQL有innodb_buffer_pool，大约为物理内存的50%-80%，内存使用率高一些，相对的性能也会提高

d)         物理内存：直线保持基本无变化，物理内存就是实际的内存条的内存大小

e)         连接数：当前连接数在1500左右，后来增高至6000左右。但是活跃连接数一直在个位数，说明现在的空闲连接数过多。总连接数超过参考值2000。出现严重问题。

数据库的连接一般是使用长连接，可能是应用侧的连接池初始连接数设置过高，应用启动后建立多个到RDS的空闲连接

解决方法：
1、长连接建议启用连接池的复用连接功能。

2、对于交互式连接和非交互式连接，建议修改相应的wait_timeout和interactive_timeout参数。（空闲时间超过指定的时间后，RDS的连接会主动关闭）。通过DT，RDS控制台，性能优化，参数设置中修改。

3、kill当前的空闲会话。

f)       线程状态：线程数跟连接数是对应的。此时也是连接的总线程数远大于活跃的线程数。

主备延迟产生的原因：

1ã  主库产生非常大的binlog

a)       主库上执行大量的dml语句

b)       主库上执行大事务

c)       主库上没有主键的全表扫描

2ã  主库上执行ddl语句，时间过长

3ã  备库上对myisam表长时间查询，阻塞主库的binlog同步语句

4ã  备库实例的规格配置低，磁盘IO比较低

查看方法:

1ã  首先查看备库的IOPS是否存在瓶颈

2ã  备库show processlist查看是否存在大事务

3ã  主库的写入压力是否过高，dml语句是否过多

4ã  只读节点执行 show slave status \G，判断是否有 Waiting for table metadata lock；同时在主库排查下是否有DDL 操作

5ã  只读节点执行 show slave status \G，判断是否有 Waiting for table level lock; 同时通过 show full processlist; 同时在主库检查下是否有长时间对 MyISAM 引擎表的查询