CPU使用率高问题排查与优化

场景描述

业务侧GaussDB(for MySQL)实例的SQL执行速率在16:08分左右开始变慢，应用有超时的报错。

原因分析

1. 查看CPU使用率监控指标，发现在16:08分左右实例的CPU使用率开始飙升到100%，且一直持续在高位线。
   图1 CPU使用率
   
2. 查看QPS、慢SQL数以及活跃连接数监控指标，发现在16:08分左右QPS突增，活跃连接数上涨，最终业务侧有较多的慢SQL产生。
   图2 QPS
   
   图3 活跃连接数
   
   图4 慢SQL数
   
3. 分析业务类型，查看16:08分前左右InnoDB的逻辑读速率有突增，且与慢SQL的速率趋势相似。
   图5 InnoDB逻辑读速率
   
4. 登录实例，查看实话会话，发现大量会话在执行SELECT COUNT(*)。

   

   EXPLAIN确认该SQL的执行计划，发现走全表扫描且单条扫描行数在35万+，其并未走索引。

   

5. 进一步查看该表的表结构，发现该表仅对字段“is_deleted”添加了一个索引“IDX_XX_USERID”，因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后，实例在16:37分左右CPU下降到正常水平，业务恢复。

解决方案

1. 建议新上业务时，提前对关键SQL通过EXPLAIN、SQL诊断等工具进行执行计划分析，根据优化建议添加索引，避免全表扫描。
2. 业务量突增的高并发造成CPU占用率高，可以考虑升级实例规格或使用独享型资源避免出现CPU资源争抢，或者创建只读实例进行读写分离减轻主实例负载。
3. 通过show processlist查看当前会话信息来辅助定位：运行状态为Sending data、Copying to tmp table、Copying to tmp table on disk、Sorting result、Using filesort的查询会话可能均包含性能问题。
4. 应急场景可以借助SQL限流以及KILL会话功能来临时kill规避“烂SQL”。