慢查询报警处理方法
所有文档

          云数据库 RDS

          慢查询报警处理方法

          背景

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

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

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

          处理过程

          问题发现

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

          1. 配置BCM监控,当触发慢查询报警的阈值时,会自动发送报警信息
          2. 查看RDS监控趋势图,观察慢查询的曲线,如下图例

            image2019-9-25_16-37-22.png

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

          问题定位

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

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

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

            举例:得到结果如下

            image.png

          2. 第二步:分析

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

          问题解决

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

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

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

          image2019-9-25_16-47-20.png

          后续处理

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

          参考资料

          监控报警操作指南

          MySQL慢日志最佳实践

          上一篇
          CPU报警处理方法
          下一篇
          MySQL慢日志最佳实践