对于尚未上线的SQL,我们可通过在测试环境去基于全量日志或者审计日志的方式,进行explain分析其是否存在ALL或affect_rows过大的情况,提前优化sql或者添加索引。
但是,如果某个sql在测试环境,表的行数很少,在测试环境中被忽略掉,进而带到生产环境,后续这个随着表行数增加,慢sql的风险也逐渐加大(因此可能出现这种情况:虽然affects_rows比较大,但是因为并发很低,导致慢查询没有记录到。但是如果并发增高的,这种就会影响到MySQL的性能)。
对此,有必要对生产运行的sql进行一些探查工作,及时找出潜在affects_rows过大的情况。
如果是开启了审计日志,则比较简单。但是审计日志又可能影响到性能,对于没有开启审计日志的话,可以使用我这种旁路式的采样方式。
思路:
1、从cmdb拉取生产的MySQL信息(集群、地址、端口、版本等)
2、轮询连接到各个MySQL,查看当前running的select查询,并对其做explain分析操作,判断type和affect_rows是否符合告警的阈值要求
3、对符合告警要求的sql,进行2个判断:
- 使用pt-fingerprint 计算sql指纹
- 判断指纹是否在redis里存在,如果不存在则发送钉钉告警并记录到redis里
- 同时将一份明细数据写到MySQL中存储(包括:sql指纹、sql样例、首次出现的时间)
注意:
1、不同版本的MySQL,explain出来的列数量是不一样的,因此type和affect_rows的判断需要根据MySQL版本来定。
代码实现起来比较简单,就不贴了。
告警示例:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。