0
0
0
0
专栏/.../

某业务升级5.0解决慢SQL问题

 18515065291  发表于  2021-06-16

某报表业务升级5.0解决慢SQL问题

                                  2021-05-07 刘春雷

1、概述

上周五早上,某商业报表业务的TiDB集群,机器频繁性能报警,导致tidb节点内存溢出,oom了~此机器包含监控节点,也导致无法查看监控来观察情况。

排查为某慢SQL导致,但存在索引,没法快速优化~

处理:

  • 联系开发,关注此慢SQL,看业务上能否暂时停止此SQL
  • DBA查看与优化

上述均无法快速解决,

  • 因之前升级5.0带来的性能提升经验,咨询业务无union all SQL(此SQL在5.0.1 版本,可能存在报错)
  • 决定快速升级至 5.0.1 版本,来提升下性能

升级后:

  • SQL执行计划有所改变,SQL执行时间立即变好, 问题解决了~
  • 最最开心的是:我们DBA中午要出去团建~着急处理,直接升级5.0,问题解决了~没耽误团建,666~

2、汇总

1

3、SQL具体

【慢SQL】:

SELECT DISTINCT eid AS eid, create_time AS create_time, product_count AS product_count
FROM xxx
WHERE

product_id = ‘5’ AND product_count >= ‘50’
ORDER BY create_time DESC
LIMIT 0, 100;

【表索引情况】:

KEY idx_xxx (product_id,product_count,create_time,eid)

【4.0.10 SQL执行时间】:

平均时间:25.3s

2


3

【4.0.10查看执行计划】:

explain SELECT DISTINCT eid AS eid,create_time AS create_time,product_count AS product_count FROM xxx WHERE (product_id = ‘5’) AND (product_count >= ‘50’) ORDER BY create_time DESC LIMIT 0, 100;

4

【5.0.1查看执行计划】:

explain SELECT DISTINCT eid AS eid,create_time AS create_time,product_count AS product_count FROM xxx WHERE (product_id = ‘5’) AND (product_count >= ‘50’) ORDER BY create_time DESC LIMIT 0, 100;

5

【5.0.1 执行时间】:

平均执行时间: 784.4ms

6

【提速的原因】:官方小伙伴给的回复:

看 执行计划是 streamagg 带来的 收益。。
4.0 是都从 tikv 捞起来在 hashagg。5.0 走 streamagg 应该是一个 pipeline 的流式处理了。要是给 2 个 explain analyze 应该能看的更准确些。
大概率 5.0的 新统计信息框架也是起到作用了

4、监控

因监控节点宕机,且修复不了,导致无法从Grafana来对比前后监控情况。但我们采集了Prometheus的监控数据,上报到我们内部的监控系统,并整合至内部CDB平台,所以我们从此平台来对比前后升级情况,如下:

可以看出升级后SQL执行时间变化了很多~

7

0
0
0
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论