tidb查询30y的数据表，有limit 1 ，目前已经超过20分钟还没出来。。。

[雪落香杉树]

tikv_gc_life_time设置时间太久了，5h，建议设置小一点30min，如果删除过大量数据，历史版本的key可能没有清除，会扫描大量key

[h5n1]

表结构看下

[TiDBer_jYQINSnf]

各位大佬，我问一句,这个全表扫，也没个索引。limit1也不是随便返回一条吧。肯定是某个顺序的第一条吧。每一次的limit 1是不是都返回同样的一条数据？
这样的话，是不是得挨个遍历？

[h5n1]

没有order by为什么要按顺序呢

[h5n1]

第一次：total_process_keys: 1, total_keys: 2914758876 read_byte: 22.8 GB
第二次： total_process_keys: 1, total_keys: 2562906823 read_byte: 19.9 GB
理论上limit下推到tikv后每个cop task只读取到1个有效记录就可以返回，感觉应该是由于大量delete后导致较多的mvcc版本，为了找到有效记录而从磁盘读取了大量历史版本记录造成的读取时间长。 看下前面两次执行随着GC的进行total keys数量是有下降的
要么就是limit下推根本就没生效

[TiDBer_jYQINSnf]

比如说，按照_table_row_id 的顺序返回第一条。总不能每次limit 1都随机返回一条吧。
假如要

select ...  limit 0,1;
select ...  limit 1,1;
select ...  limit 2,1;

最终要遍历完一张表的啊。如果随即返回，岂不是永远无法拿到整张表啊。
这样的话，limit下推后，怎么实现的只取1条数据就是应该取的那一条？

[h5n1]

既然没指定排序，那就随机，limit下推到tikv还要全表扫描一遍，那这个limit 意义不太大吧

[TiDBer_jYQINSnf]

如果纯随机的话，那我上面说的类似翻页的功能，岂不是翻不完一张表？

[h5n1]

貌似分页不是这么分的

[Hacker_xUwtuKxa]

我实际测试了一下，虽然使用了tableFullScan算子，但是limit中的process keys的数量为1，说明limit算子是起作用了的，但total keys的数量还高，是由于delete_skip_count与key_skipped_count数量很高，导致整体扫描的keys数量很高。因此这与GC的life time设置较长有关。
但问题处在tidb侧的tableReader算子，用时在这一层花了20m37.8s，主要都在rpc_time上，因此可以看看为什么在这里花费了这么多的时间？

[Z六月星星]

应该就是走全表扫描了