tidb SQL执行时间不稳定

[qiuxb]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
4.0.8

【概述】 场景 + 问题概述
在线上tidb上跑了很久的SQL，执行时间都在0.8s左右，现在偶尔出现执行达到600s还不结束，cpu和内存使用率都正常，手动执行又很快还是0.8s，手动获取执行计划上也没有什么异常，目前无法分析具体的原因

执行计划
±---------------------------------------------------------------±--------±-------------±----------------------------------------------------------------------------------------------------------
| id | estRows | task | access object
±---------------------------------------------------------------±--------±-------------±----------------------------------------------------------------------------------------------------------
| Projection_23 | 1.00 | root |
| └─TopN_26 | 1.00 | root |
| └─HashAgg_32 | 1.00 | root |
| └─Projection_133 | 0.01 | root |
| └─HashJoin_40 | 0.01 | root |
| ├─HashJoin_42(Build) | 0.01 | root |
| │ ├─IndexJoin_50(Build) | 0.00 | root |
| │ │ ├─IndexJoin_70(Build) | 0.00 | root |
| │ │ │ ├─IndexJoin_84(Build) | 0.00 | root |
| │ │ │ │ ├─HashJoin_90(Build) | 0.00 | root |
| │ │ │ │ │ ├─IndexLookUp_100(Build) | 0.00 | root |
| │ │ │ │ │ │ ├─IndexRangeScan_97(Build) | 2.30 | cop[tikv] | table:crea, index:idx_adid(advertisement_id)
| │ │ │ │ │ │ └─Selection_99(Probe) | 0.00 | cop[tikv] |
| │ │ │ │ │ │ └─TableRowIDScan_98 | 2.30 | cop[tikv] | table:crea
| │ │ │ │ │ └─Point_Get_109(Probe) | 1.00 | root | table:t_ad_advertisement
| │ │ │ │ └─TableReader_83(Probe) | 1.00 | root |
| │ │ │ │ └─TableRangeScan_82 | 1.00 | cop[tikv] | table:gro
| │ │ │ └─TableReader_69(Probe) | 1.00 | root |
| │ │ │ └─TableRangeScan_68 | 1.00 | cop[tikv] | table:cam
| │ │ └─IndexLookUp_49(Probe) | 1.00 | root |
| │ │ ├─Selection_48(Build) | 1.00 | cop[tikv] |
| │ │ │ └─IndexRangeScan_46 | 1.00 | cop[tikv] | table:acc, index:uniq_uuid(uuid)
| │ │ └─TableRowIDScan_47(Probe) | 1.00 | cop[tikv] | table:acc
| │ └─TableReader_122(Probe) | 231.00 | root |
| │ └─TableRangeScan_121 | 231.00 | cop[tiflash] | table:norm
| └─IndexLookUp_132(Probe) | 443.21 | root |
| ├─IndexRangeScan_129(Build) | 443.66 | cop[tikv] | table:t_statistics_stats_hour, partition:p20220802, index:idx_advertiser_hour(advertiser_id, report_time)
| └─Selection_131(Probe) | 443.21 | cop[tikv] |
| └─TableRowIDScan_130 | 443.66 | cop[tikv] | table:t_statistics_stats_hour, partition:p20220802
±---------------------------------------------------------------±--------±-------------±----------------------------------------------------------------------------------------------------------
【背景】 做过哪些操作

【现象】 业务和数据库现象
从tidb的监控看，有看到SQL执行的时间点，tiflash的io util有上升到80%

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
4.0.8
【应用软件及版本】

【附件】 相关日志及配置信息

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）

---

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[qiuxb]

当前tidb部署架构，3个pd 2个tidb 1个tiflash

[TiDBer_jYQINSnf]

600s的执行计划和0.8s的执行计划一样吗？

[qiuxb]

目前没办法复现出来，也就不知道600s的执行计划是什么样的，另外如果查询自动走tiflash会有问题么？

[ddhe9527 (多多)]

可以在dashboard或statement summary tables表中捞一下这个SQL的执行计划，看有没有多个

[qiuxb]

dashboard貌似是有bug的，上次看SQL执行计划，tidb一个实例就oom了，satement summary table会不会也有这样问题?

[h5n1]

tidb的slowlog文件或CLUSTER_SLOW_QUERY里找到慢SQL，然后把 Plan_digest 用 tidb_decode_plan()函数解析下就有执行计划了

[cheng]

select plan ,plan_digest,digest_text from information_schema.statements_summary
– 或者 statement_summary_history where digest=’’

[buddyyuan]

这个是预期的，dashboard 也是基于这些内存视图的，statement_summary，statement_summary_history 这些都是内存视图，你只要实例重启了，相关实例的 SQL 信息都清空了。

你只能从slow log 中找到慢SQL，在用tidb_decode_plan转换出执行计划