一种轻量级的潜在慢SQL巡检思路

对于尚未上线的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版本来定。

代码实现起来比较简单，就不贴了。

告警示例：