作者： 18515065291 原文来源：https://tidb.net/blog/50162183

某报表业务升级 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 执行时间变化了很多~