关于tidb上索引使用的问题

🪐 TiDB 技术问题
, ,
1

【TiDB 使用环境】生产环境
【TiDB 版本】8.5.1
【操作系统】rockylinux
【部署方式】机器部署（96vcpu 256G、nvme硬盘）
【集群数据量】8T
【集群节点数】3tikv+3tiflash
【问题复现路径】查询
【遇到的问题：问题现象及影响】同一个sql查询 查询条件不同执行计划不同，想请教一下是什么原因
表t 有19亿+的数据 。其中agent_no_tree LIKE concat(‘101106,103264’, ‘%’) 占了10亿+ 的数据

以下是两个sql以及执行计划，表t的索引有idx_oatime(order_time,agent_no_tree,project_no)

SELECT /*+ read_from_storage(tiflash[t,p]) / count() FROM t_agent_order t LEFT JOIN t_agent_project p ON t.project_no = p.project_no WHERE 1 = 1 AND t.order_time BETWEEN ‘20250501000000’ AND ‘20250531235959’ AND t.agent_no_tree LIKE concat(‘101106,129456’, ‘%’);

image
image1896×285 17.8 KB

SELECT /*+ read_from_storage(tiflash[t,p]) / count() FROM t_agent_order t LEFT JOIN t_agent_project p ON t.project_no = p.project_no WHERE 1 = 1 AND t.order_time BETWEEN ‘20250501000000’ AND ‘20250531235959’ AND t.agent_no_tree LIKE concat(‘101106,103264’, ‘%’);

image
image1887×568 20.9 KB

以上两个执行计划，其中的push down filter的字段不一样，在我的理解当中应该是先通过order_time 去划分范围 ，然后再根据agent_no_tree 去过滤才对，所以不太理解这个执行计划的结果，想请问一下是什么原因导致的

2

你当前看的执行计划是根据统计信息生成的，最终的执行计划可能不是这个。
explain analyze 看真实的执行计划。

3

t.order_time BETWEEN ‘20250501000000’ AND ‘20250531235959’ AND t.agent_no_tree LIKE concat(‘101106,129456’, ‘%’);
这两个条件push down filter用哪个完全取决于你的统计信息里面哪个字段的过滤效果更好，没有应该走哪个更合理的说法。

4

这并不是用到了索引，tiflash 是列式存储，每列本身就是索引，至于执行计划里出现的 push down，是 tiflash 延迟物化功能，与参数 tidb_opt_enable_late_materialization 有关，延迟物化是优化器自己判断选择的，可以看下：https://docs.pingcap.com/zh/tidb/stable/tiflash-late-materialization/

1 个赞