云数据库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慢日志最佳实践