一次sql优化和业务场景优化的记录

本文主要是介绍一次sql优化和业务场景优化的记录，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

一次sql优化和业务场景优化的记录：

1.测试场景及问题描述：

–对接cmp容器管理平台，需要将我方系统采集到的容器资源指标信息，以5分钟为颗粒度发送至cmp对应的接口，大致的处理逻辑为：

—原始指标采集，分析，落库；；

—定时任务执行sql查询，并过滤出对应指标，查询出最近5min的结果，（basic_tsdb大宽表，行极多）不到4亿数据

—转化成对应的接口格式，通过接口反馈给cmp系统；

–问题：（1）kafka对应消费组消费堆积；（2）定时任务执行时，sql报错执行超时，影响对应接口获取不到数据

2.分析及解决问题思路：

针对问题（1）：

—查看了各节点的消费堆积分布，排除了偏移量不均问题；

—查看了sink（消费者）日志，没有明显报错，排除功能影响导致数据不能入库问题；

—查看了ck（数据库）状态，及磁盘读写负载，没有看到明显瓶颈，排除资源问题；

因此推测为消费能力没有得到完全释放：

故增大了消费者的task属性值（提高消费线程，使task数=topic*partitions数量）；

重建了kafka-topic，清除已堆积的数据；

修改了collector（数据收集器）的采集上报频率，由5s增大至1min（求稳）；

针对问题（2）：

—直接把sql在客户端执行了一遍，30s超时（客户端默认配置），推测为数据库性能问题或sql问题；

—查看sql，没有select*等小白问题，存在字符串转换函数，关联查询，分组，过滤等

—查看数据库cpu使用情况（ck特性为查询默认消耗所在机器一半的CPU核数，功能环境adb未和产品组件拆分部署，存在资源争抢），60%左右，没有达到瓶颈；

—鉴于和开发说了sql问题，他不认，使用了ck的解析计划，分析了sql执行过程：（几乎全表扫描，就查出了35条）

优化思路：先通过时间范围和系统id缩小结果集，再过滤全部指标

优化后：

这篇关于一次sql优化和业务场景优化的记录的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！