场景描述

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

原因分析

查看CPU使用率监控指标，发现在16:08分左右实例的CPU使用率开始飙升到100%，且一直持续在高位线。

图1 CPU使用率

查看QPS、慢SQL数以及活跃连接数监控指标，发现在16:08分左右QPS突增，活跃连接数上涨，最终业务侧有较多的慢SQL产生。

图2 QPS

图3 活跃连接数

图4 慢SQL数

分析业务类型，查看16:08分前左右InnoDB的逻辑读速率有突增，且与慢SQL的速率趋势相似。

图5 InnoDB逻辑读速率

登录实例，查看实话会话，发现大量会话在执行SELECT COUNT(*)。

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

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

解决方案

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

父主题： 性能资源类

同意关联代理商云淘科技，购买华为云产品更优惠（QQ 78315851）

内容没看懂？ 不太想学习？想快速解决？ 有偿解决： 联系专家