【故障解读】v5.1.1-调整变量 tidb_isolation_read_engines 影响 tiflash SQL 执行计划

作者介绍

杨晓军，携程 DBA，对分布式数据库充满好奇和兴趣，希望在 TUG 能学习到更多知识交到更多朋友。

问题现象

SQL：SELECT count(*) FROM (SELECT DISTINCT t1.uid FROM cdp_crm_uid_detail_basic t1 WHERE (t1.message_locale IN ( 'en-ie', 'en-us','ms-my','en-ae','en-my','en-au','ja-jp', 'de-de', 'zh-hk' ) AND flt_ord_num_s IS NULL AND htl_ord_num_s IS NULL) OR ( t1.message_locale = 'ru-ru' AND flt_ord_num_s IS NULL AND htl_ord_num_s IS NULL AND t1.edm_discounts_subscribe = 1)) a;

Set tidb_isolation_read_engines='tidb,tikv,tiflash'时，执行计划会使用 streamAgg

Set tidb_isolation_read_engines='tidb,tiflash'时，SQL 执行计划还走 tiflash 引擎，但算子变成了 hashagg ，耗时明显增加，内存开销非常高，甚至会导致 tidb 发生 OOM ，变化后的执行计划如下：

虽然表的健康度只有 67，但 SQL 只走 tiflash 引擎，应该跟 tikv 本身没有关系才对，不太理解为何调整变量 tidb_isolation_read_engines 会导致优化器的评估出现差异？

原因分析

TiFlash 支持的下推算子中可以确认不带GROUP BY 条件的列可以进入下推：

可见案例中的 steamAgg 在默认情况下是支持下推到 tiflash 的，但从 session 变量 tidb_isolation_read_engines 中去除了 tikv 之后，下推入口是否被挡住了。查看执行计划生成源码https://github.com/pingcap/tidb/blob/v5.1.1/planner/core/exhaust_physical_plans.go#L2362 可以确认当 datasource 不再有 tikv access path 时会变为 RootTask，RootTaskType 最终会生成不下推 agg 的计划；