某报表业务升级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、汇总
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
【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;
【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.0.1 执行时间】：
平均执行时间： 784.4ms
【提速的原因】：官方小伙伴给的回复：
看 执行计划是 streamagg 带来的 收益。。
4.0 是都从 tikv 捞起来在 hashagg。5.0 走 streamagg 应该是一个 pipeline 的流式处理了。要是给 2 个 explain analyze 应该能看的更准确些。
大概率 5.0的 新统计信息框架也是起到作用了
4、监控
因监控节点宕机，且修复不了，导致无法从Grafana来对比前后监控情况。但我们采集了Prometheus的监控数据，上报到我们内部的监控系统，并整合至内部CDB平台，所以我们从此平台来对比前后升级情况，如下：
可以看出升级后SQL执行时间变化了很多~
