背景
数据库性能的优劣，直接关系到系统执行的效率和稳定性，如果出现性能问题不仅会损害公司形象，也可能会造成公司资金方面的损失。慢SQL是影响数据库性能很重要的一个方面。对于海量数据，劣质SQL和优质SQL之间的速度差别可能达到上百倍，解决慢SQL对解决数据库性能问题会起到事半功倍的效果。
当数据库出现性能问题时，大多数时候跟慢SQL有关。慢SQL问题比较严重时，通常会有如下一些表现：
- 数据库响应变慢，SQL执行耗时变长，最终业务请求超时
- 数据库读和写的QPS降低
- 系统资源CPU打满等现象
处理过程
问题发现
慢查询问题的发现渠道有如下几种：
- 配置BCM监控，当触发慢查询报警的阈值时，会自动发送报警信息
-
查看RDS监控趋势图，观察慢查询的曲线，如下图例
- 业务访问数据库响应变慢，也可能是因为慢查询
问题定位
-
第一步：确认是否存在预期中的长耗时SQL
登录及查看命令数据库命令：
mysql -h 实例ip -P端口 -u用户 -p密码 -e " SHOW PROCESSLIST;" |grep -ivw sleep
举例：得到结果如下
-
第二步：分析
通过当前 processlist 展示结果，可以看到有6个长耗时的慢SQL，导致了慢查询报警
问题解决
首先需要确认这些慢查询是否可以终止，如果可以终止，登录RDS执行KILL命令： KILL threadID; #比如 kill 10276 ;,遍历 kill 6个sessionid
这时客户端会收到报错信息如下，这是符合预期的： ERROR 2006 (HY000): MySQL server has gone away
如上例，观察监控趋势图：慢查询个数减少并逐步消失
后续处理
- 直接对kill线上慢查询，只是对线上正在出现问题的紧急处理
- 如果是存量慢SQL，建议尽快对相关SQL优化处理（如加索引、优化SQL访问方式等）
- 如果是新增慢SQL，为避免对现有服务造成影响,建议将服务暂时下线，待优化后再上线
参考资料
监控报警操作指南
MySQL慢日志最佳实践
