概览

数据库性能的优劣，直接关系到系统执行的效率和稳定性，如果出现性能问题不仅会损害公司形象，也可能会造成公司资金方面的损失。慢SQL是影响数据库性能很重要的一个方面。对于海量数据，劣质SQL和优质SQL之间的速度差别可能达到上百倍，解决慢SQL对解决数据库性能问题会起到事半功倍的效果。

需求场景

当数据库出现性能问题时，大多数时候跟慢SQL有关。慢SQL问题比较严重时，通常会有如下一些表现：

1. 数据库响应变慢，SQL执行耗时变长，最终业务请求超时。
2. 数据库读和写的QPS降低。
3. 系统资源CPU打满等现象。

问题发现

慢查询问题的发现渠道有如下几种：

1. 配置BCM监控，当触发慢查询报警的阈值时，会自动发送报警信息

2. 查看RDS监控趋势图，观察慢查询的曲线，如下图例

   

3. 业务访问数据库响应变慢，也可能是因为慢查询

问题定位

1. 第一步：确认是否存在预期中的长耗时SQL。

   登录及查看命令数据库命令：

   mysql -h 实例ip -P端口 -u用户 -p密码 -e " SHOW PROCESSLIST;" |grep -ivw sleep；

   举例：得到结果如下：

   

2. 第二步：分析。

   通过当前 processlist 展示结果，可以看到有6个长耗时的慢SQL，导致了慢查询报警。

问题解决

首先需要确认这些慢查询是否可以终止，如果可以终止，登录RDS执行KILL命令： KILL threadID; ，#比如 kill 10276 ;，遍历 kill 6个sessionid

这时客户端会收到报错信息如下，这是符合预期的： ERROR 2006 (HY000): MySQL server has gone away 。

如上例，观察监控趋势图：慢查询个数减少并逐步消失。

后续处理

1. 直接对kill线上慢查询，只是对线上正在出现问题的紧急处理。
2. 如果是存量慢SQL，建议尽快对相关SQL优化处理（如加索引、优化SQL访问方式等）。
3. 如果是新增慢SQL，为避免对现有服务造成影响,建议将服务暂时下线，待优化后再上线。

参考资料

监控报警操作指南。

MySQL慢日志典型实践。

相关产品

云监控BCM：全面、可靠、及时的监控服务。