rds for mysql cpu升高定位思路-j9九游会登录

场景1 慢查询导致cpu升高

问题原因：大量慢sql导致实例cpu升高，需要优化相应的慢sql。

排查思路：

查看cpu使用率和慢日志个数统计监控指标。

• 如果慢日志个数很多，且与cpu曲线吻合，可以确定是慢sql导致cpu升高。
• 如果慢日志个数不多，但与cpu使用率基本一致，进一步查看行读取速率指标是否与cpu曲线吻合。

  

  如果吻合，说明是少量慢sql访问大量行数据导致cpu升高：由于这些慢sql查询执行效率低，为获得预期的结果需要访问大量的数据导致平均io高，因此在qps并不高的情况下（例如网站访问量不大），也会导致实例的cpu使用率偏高。

j9九游会登录的解决方案：

1. 根据cpu使用率过高的时间点，查看对应时间段的慢日志信息。
2. 重点关注扫描行数、返回结果行数超过百万级别的慢查询，以及锁等待时间长的慢查询。
3. 慢查询用户可自行分析，或使用数据管理服务(das)的对慢查询语句进行诊断。
4. 使用数据库代理 只读实例架构，实现读写分离。只读实例专门负责查询，减轻主库压力，提升数据库吞吐能力，详见。
5. 通过分析数据库执行中的会话来定位执行效率低的sql。
   1. 连接数据库。
   2. 执行show full processlist;。
   3. 分析执行时间长、运行状态为sending data、copying to tmp table、copying to tmp table on disk、sorting result、using filesort的会话，均可能存在性能问题，通过会话来分析其正在执行的sql。

场景2 连接和qps升高导致cpu上升

问题原因：业务请求增高导致实例cpu升高，需要从业务侧分析请求变化的原因。

排查思路：

查看qps、当前活跃连接数、数据库总连接数、cpu使用率监控指标是否吻合。

qps的含义是每秒查询数，qps和当前活跃连接数同时上升，且qps和cpu使用率曲线变化吻合，可以确定是业务请求增高导致cpu上升，如下图：

该场景下，sql语句一般比较简单，执行效率也高，数据库侧优化余地小，需要从业务源头优化。

j9九游会登录的解决方案：

1. 单纯的qps高导致cpu使用率过高，往往出现在实例规格较小的情况下。例如：1u、2u、4u，建议升级实例cpu规格。
2. 优化慢查询，优化方法参照场景1 慢查询导致cpu升高的j9九游会登录的解决方案。若优化慢查询后效果不明显，建议升级实例cpu规格。
3. 对于数据量大的表，建议通过分库分表减少单次查询访问的数据量。
4. 使用数据库代理 只读实例架构，实现读写分离。只读实例专门负责查询，减轻主库压力，提升数据库吞吐能力，详见。