MySQL慢查询报警处理最佳实践
概览
数据库性能的优劣，直接关系到系统执行的效率和稳定性，如果出现性能问题不仅会损害公司形象，也可能会造成公司资金方面的损失。慢SQL是影响数据库性能很重要的一个方面。对于海量数据，劣质SQL和优质SQL之间的速度差别可能达到上百倍，解决慢SQL对解决数据库性能问题会起到事半功倍的效果。
需求场景
当数据库出现性能问题时，大多数时候跟慢SQL有关。慢SQL问题比较严重时，通常会有如下一些表现：
- 数据库响应变慢，SQL执行耗时变长，最终业务请求超时。
- 数据库读和写的QPS降低。
- 系统资源CPU打满等现象。
问题发现
慢查询问题的发现渠道有如下几种：
- 配置BCM监控，当触发慢查询报警的阈值时，会自动发送报警信息。
- 查看RDS监控趋势图，观察慢查询的曲线，如下图例。
- 业务访问数据库响应变慢，也可能是因为慢查询。
问题定位
-
第一步：确认是否存在预期中的长耗时SQL。
登录及查看命令数据库命令：
mysql -h 实例ip -P端口 -u用户 -p密码 -e " SHOW PROCESSLIST;" | grep -ivw sleep;
举例：得到结果如下：
Id User Host db Command Time State Info 1 event_schedulerlocalhost (null) Daemon 80375Waiting on empty queue(null) 12 _xxx 192.168.0.230:60158 (null) Binlog Dump GTID80321Master has sent all binlog to slave; waiting for more updates(null) 171 _xxx 192.168.0.237:44040 (null) Binlog Dump GTID79129Master has sent all binlog to slave; waiting for more updates(null) 10276 wxx_w 192.168.0.233:44738 baidu_dba Query 31 Sending data select intcol1 from t1 where charcol1 like '%uLFqdGGIrm8ivjdtPb%' 10277 wxx_w 192.168.0.233:44742 baidu_dba Query 30 Sending data select intcol1 from t1 where charcol1 like '%uLFqdGGIrm8ivjdtPb%' 10278 wxx_w 192.168.0.233:44740 baidu_dba Query 31 Sending data select intcol1 from t1 where charcol1 like '%uLFqdGGIrm8ivjdtPb%' 10279 wxx_w 192.168.0.233:44736 baidu_dba Query 31 Sending data select intcol1 from t1 where charcol1 like '%uLFqdGGIrm8ivjdtPb%' 10280 wxx_w 192.168.0.233:44744 baidu_dba Query 31 Sending data select intcol1 from t1 where charcol1 like '%uLFqdGGIrm8ivjdtPb%' 10312 _root localhost mysql Query 0 starting SHOW PROCESSLIST
- 第二步：分析：通过当前 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，为避免对现有服务造成影响,建议将服务暂时下线，待优化后再上线。
参考资料
相关产品
云监控BCM：专业、可靠、及时的监控服务。