4.0.13版本的tiflash会导致索引失效吗？

🪐 TiDB 技术问题 性能调优
1

tidb 4.0.13版本

背景：
我们有个查询平台，有时候业务会做一些大查询，为了避免查询平台的查询影响到线上的流量，我们使用了tiflash，且单独配置了一个tidb节点，这个节点是强制所有查询都是用tiflash。

今天业务反馈，有个索引等值查询的sql在查询平台很慢，但是在代码里查询很快，经过排查发现该sql在tiflash执行的时候全表扫描，但是该查询的查询条件是索引，且等值查询，数据类型也一致，不太理解为啥会全表扫描。

图片
图片1611×789 59 KB

下面是在tikv的执行计划

图片
图片1307×150 10.1 KB

mysql> explain analyze SELECT * FROM dbzz_financialcenter.outbound_order_sku t where sales_order_no = '3127937763871982738';
+--------------------------+--------------+-----------+--------------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+---------+------+
| id                       | estRows      | actRows   | task         | access object | execution info                                                                                                                                         | operator info                                                                     | memory  | disk |
+--------------------------+--------------+-----------+--------------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+---------+------+
| TableReader_7            | 6.67         | 1         | root         |               | time:47.2s, loops:2, cop_task: {num: 2194, max: 1.32s, min: 75.2ms, avg: 320ms, p95: 541.6ms, rpc_num: 2194, rpc_time: 11m42.1s, copr_cache: disabled} | data:Selection_6                                                                  | 1.48 KB | N/A  |
| └─Selection_6            | 6.67         | 1         | cop[tiflash] |               | tikv_task:{proc max:1.32s, min:73.7ms, p80:433.8ms, p95:538.9ms, iters:1, tasks:2194}                                                                  | eq(dbzz_financialcenter.outbound_order_sku.sales_order_no, "3127937763871982738") | N/A     | N/A  |
|   └─TableRangeScan_5     | 326965626.00 | 326952756 | cop[tiflash] | table:t       | tikv_task:{proc max:1.31s, min:73.7ms, p80:420ms, p95:523.8ms, iters:9039, tasks:2194}                                                                 | range:[0,+inf], keep order:false                                                  | N/A     | N/A  |
+--------------------------+--------------+-----------+--------------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+---------+------+
3 rows in set (47.85 sec)

mysql>
2

看下统计信息收集的是否准确

3

写错了吧 Tidb有4版本吗
在一些SQL调优案例中，即使表的过滤字段建有索引，优化器仍可能选择走TiFlash查询而不是预期的走索引查询，但这并非表明是TiFlash导致索引失效

4

执行计划了，优化器更倾向全表了有可能

5

索引失效是什么意思呢，这个可能只是根据代价评估走 tiflash 代价低，低版本用 tiflash 功能要保守点用

1 个赞
6

优化器根据统计信息估算的执行计划，可以手动收集统计信息。

7

当前走到 TiFlash 引擎都会显示走全表扫描的，因为 TiFlash 本身就是列式存储，没有索引的概念。

你这里的问题，其实应该是本来应该走到 TiKV 的查询，为什么走到了 TiFlash？ 有 analyze table 重新生成统计信息么？

8

重新收集一下统计信息，再看执行计划。

9

:thinking:有的啊，还有2.0，3.0的

10

tiflash是列存，使用tiflash查询的时候，只有全表扫描，不会走索引。

1 个赞
11

收集下统计信息，或者指定下hint，引擎指定tikv

12

4.0的tiflash不是很稳定，hint参考Optimizer Hints