explain 执行计划中怎么理解key_skipped_count

背景:对tpch的orders进行测试
发现执行计划中的key_skipped_count 令人困惑,不知道真正的含义是什么?
备注:没有删除过数据,tpch的orders的表数据生成以后,就直接count了
mysql> select count() from orders where O_ORDERDATE >= “1995-01-01” and O_ORDERDATE <= “1995-01-03”;
±---------+
| count(
) |
±---------+
| 1811 |
±---------+
1 row in set (0.00 sec)

mysql> explain analyze select count(*) from orders where O_ORDERDATE >= “1995-01-01” and O_ORDERDATE <= “1995-01-03”;
±----------------------------±--------±--------±----------±---------------------------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------±----------±-----+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±----------------------------±--------±--------±----------±---------------------------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------±----------±-----+
| StreamAgg_17 | 1.00 | 1 | root | | time:2.56ms, loops:2 | funcs:count(Column#12)->Column#10 | 388 Bytes | N/A |
| └─IndexReader_18 | 1.00 | 1 | root | | time:2.55ms, loops:2, cop_task: {num: 1, max: 2.49ms, proc_keys: 1811, rpc_num: 1, rpc_time: 2.47ms, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15} | index:StreamAgg_9 | 267 Bytes | N/A |
| └─StreamAgg_9 | 1.00 | 1 | cop[tikv] | | tikv_task:{time:1ms, loops:2}, scan_detail: {total_process_keys: 1811, total_process_keys_size: 83306, total_keys: 1812, get_snapshot_time: 890.3µs, rocksdb: {key_skipped_count: 1811, block: {cache_hit_count: 9}}} | funcs:count(1)->Column#12 | N/A | N/A |
| └─IndexRangeScan_16 | 257.81 | 1811 | cop[tikv] | table:orders, index:O_ORDERDATE(O_ORDERDATE) | tikv_task:{time:1ms, loops:2} | range:[1995-01-01,1995-01-03], keep order:false | N/A | N/A |
±----------------------------±--------±--------±----------±---------------------------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------±----------±-----+
4 rows in set (0.01 sec)

先 analyze 表分析要,要不执行计划有问题

跳过的索引key的数量。这个值通常在使用了索引的情况下非零。

Rocksdb_key_skipped_count:RocksDB 扫数据时遇到的已删除 (tombstone) Key 数量。

1 个赞

请问这个怎么理解呢

我这里没看到这种情况,楼主是有对表删除过吗?

其实就是删除了的数据,但是还没gc掉,tikv扫描的时候需要过滤掉这些数据

1 个赞

删除数据的时候,并不是直接把这条数据删了,而是标记为删除。改了下状态。
更新数据也是同理,写了一条新数据,老数据标记为删除。
等到tikv gc的时候,才真正的删掉这条记录。

这个数字大,说明这个表更新/删除频繁。
如果gc正常推进,说明业务就是这样可以不管。
gc推进的情况可以进grafana 里面tikv details 面板gc那个分组里面去看。

1 个赞