TIDB升级到8.5.6后，应用端语句执行变慢

🪐 TiDB 技术问题
, ,
21

表的健康度没有问题，都是100，或者接近100；统计信息也没有问题，从执行计划看预估行和实际行没有太大区别，说明统计信息是准确的。

22

analyze table

23

先做一下全库的表分析

24

iDB v8.5.6 优化器 / 执行引擎行为变更 + TiFlash 读取 / 数据传输阻塞，导致 SQL 触发了低效的 MPP + TiFlash 并行执行模式，出现严重的pipeline_queue_wait（流水线队列等待）、fetch and wait（数据拉取等待）、local_stream（本地流等待），全部是执行引擎内部等待耗时，而非 CPU/IO/ 内存瓶颈。

25

目的是什么呢？

26

有什么解决方法吗？

27

其他表也添加tifalsh，并且通过hint从tiflash读取数据会不会变快？

28

联查的表都在tiflash上吗

29

原来有7，8个表都添加了tiflash，后来发现添加到tiflash的这些表都会有一样的问题，把它们在tiflash删除后，就没有再出现这样的问题了

30

原来有一些是在tiflash的，有些不在tiflash，我试过都推到tiflash，但还是会有一样的问题

31 
    └─HashJoin_50(Probe)           |12372.01|21286  |root        |                                     |time:20.6ms, loops:30, build_hash_table:{total:17.7ms, fetch:15.4ms, build:2.3ms}, probe:{concurrency:5, total:106.4ms, max:21.5ms, probe:9.59ms, fetch and wait:96.8ms}                                                                                       |left outer join, equal:[eq(MB.O_amazoncomments.sku, MB.O_skulist.number)]                                                                                                                     |1.12 MB |0 Bytes|
      ├─Projection_51(Build)       |12372.01|21286  |root        |                                     |time:16.1ms, loops:24, Concurrency:5                                                                                                                                                                                                                           |MB.O_amazoncomments.sku, upper(MB.O_amazoncomments.site)->Column#157                                                                                                                          |377.5 KB|N/A    |
      │ └─TableReader_59           |12372.01|21286  |root        |partition:P_LT_2026-06-01 00:00:00   |time:15.8ms, loops:24, cop_task: {num: 20, max: 0s, min: 0s, avg: 0s, p95: 0s, copr_cache_hit_ratio: 0.00}                                                                                                                                                     |MppVersion: 2, data:ExchangeSender_58                                                                                                                                                                               |534.8 KB|N/A    |
      │   └─ExchangeSender_58      |12372.01|21286  |mpp[tiflash]|                                     |tiflash_task:{time:14ms, loops:29, threads:48}                                                                                                                                                                                                                 |ExchangeType: PassThrough                                                                                                                                                                                           |N/A     |N/A    |
      │     └─TableFullScan_56     |12940.00|21286  |mpp[tiflash]|table:T1                             |tiflash_task:{time:14ms, loops:29, threads:48}, tiflash_scan:{mvcc_input_rows:41274, mvcc_input_bytes:1485864, mvcc_output_rows:32006, lm_skip_rows:0, local_regions:1, remote_regions:0, tot_learner_read:1ms, region_balance:{instance_num: 1, max/min: 1/1=1|pushed down filter:ge(MB.O_amazoncomments.commentdate, 2026-05-07 00:00:00.000000), lt(MB.O_amazoncomments.commentdate, 2026-05-20 00:00:00.000000), keep order:false, PartitionTableScan:true|N/A     |N/A    |

如果你最终结果集不高，并且不需要全扫数据的话，没必要走 tiflash。
tiflash 本身 mpp 的话，对于 join、大数量聚合更有优势。

32

现在没有走tiflash了，关键是为什么会有这种情况出现，要是一直都走不了tiflash，那tiflash就没啥用了

33

你们 tiflash 是什么配置，有多少个节点。
tikv 有多少个节点，每个节点什么配置

tiflash 主要做资源隔离、实时分析、MPP 计算。
分工不一样的。

34

image
image1350×738 26.4 KB

tiflash一共有6个节点，其中3个节点是和tikv混合部署，另外3个节点是tiflash专用，配置如图所示。

35

tiflash 和 tikv 混合部署做了资源隔离了么？
tiflash 一般都独立部署。主要因为 tiflash mpp 特性，还是比较吃网络带宽的。

tiflash 数量不算少，不过你之前数据库端 ms 级别，其实 ms 级别没必要走 tiflash。
tiflash 推荐是那种 tikv 秒级或者 join 跑不出来的跑批场景或者大范围聚合场景用的。

37

检查 TiDB 的升级日志，看是否有明显的错误或警告信息

38

没有做资源隔离。
目前表的数据量有几百万，没走tiflash的情况下，应用端还可以接受，后续数据量上来后，还是要走tiflash。

39

更新过统计信息了，从执行计划就可以看出来，预估行数是准确的。

40

没看到有明显的错误或警告信息

41

开启慢查询日志 ‌: 如果慢查询日志没有开启，可以开启并设置一个较低的阈值（例如 100ms），以便捕获所有执行时间超过该阈值的查询