参考文档：
根据IndexLookUp的解释：
先汇总Build端TiKV扫描上来的RowID；这里的汇总操作是由tidb-server来汇总么而不是直接在TiKV进行汇总？然后再由tidb-server根据RowID去TiKV查询数据么？
tidb server汇总的，执行计划里task列 显示root的都是在tidb server，显示cop[tikv或tiflash]的都是在tikv/tiflash完成的，你可以试试关闭topn_push_down下推规则然后对比下limit语句执行后tikv返回tidb的流量大小
禁用limit下推
INSERT INTO mysql.opt_rule_blacklist VALUES(“topn_push_down”);
ADMIN reload opt_rule_blacklist;
启用limit下推
delete from mysql.opt_rule_blacklist;
ADMIN reload opt_rule_blacklist;
那么意味着，如果在IndexLookUp算子下，如果tikv返回100万条数据给tidb-server，然后再由tidb-server根据rowid去tikv查询对应的匹配行，这中间占用的资源应该非常大？
如果tikv可以直接根据100万条数据的rowid来查询，只要返回最终的结果给tidb-server，那资源占用应该很少
rowid 这种只能返回给tikv的上层算子，不会把rowid返回给tidb server， 根据rowid回表后再返回tidb server
上层算子是IndexLookUp，这个算子是应该是在tidb-server层的？
所以tidb-server这层还是会收到100万条数据量？
会的，如果多个tikv，需要知道各个rowid所在在的tikv节点region节点 这个tidb-server通过pd可以知道
经过索引条件过滤后的数据，join在tidb server层
这个意思是回表操作是直接在tikv层做了，下面从索引获取的00万条数据不会返回给tidb-server而是在tikv层直接做回表操作了？
如果是这样子上面说的，对于IndexLookUp算子，先汇总Build端TiKV扫描上来的RowID，这个汇总操作应该是tikv层来汇总的？然后直接由tikv层来做rowid回表操作？
IndexLookUp 这种指的就是需要扫描索引然后回表的操作，可以理解成 tidb要执行一个IndexLookUp任务，这个任务下发到tikv层就是扫描索引然后回表 过滤后返回IndexLookUp。你可看看下IndexLookUp的子算子一个是scan index 一个是tablescan by rowid，两个都cop(tikv)
谢谢回复
子算子是都在tikv层，但是对于scan index返回的100万条数据量（假设100万条），tikv有没有返回这100万条数据量给tidb-server，然后tidb-server在根据rowid来从tikv查询数据？
根据上面的解释，貌似tikv进行scan index之后，会把数据先返回给tidb-server，然后再由tidb-server根据rowid进行回表操作？
这个执行过程 IndexRangeScan_38(Build) cop[tikv]在tikv扫描索引，TableRowIDScan_39(Probe) cop[tikv]然后根据rowid回表查询 ，最后返回上层算子
那就是在tikv层执行IndexRangeScan获取的数据不会返回给tidb-server了，而是执行tableRowIDScan之后才返回数据给tidb-server
是的，只要task列带cop[tikv] 的都得在tikv执行的
执行计划的执行顺序是 先执行子算子 ，同级的子算子先执行上面的，然后向父算子返回数据。看这个官档的描述是有点rowid返回tidb的意思
1 个赞
好的，非常感谢，明白了
我也得再研究下，看官档感觉可能我的理解有些偏差
你们研究的好细致，学习了。
确认了下，这个确实是先indexscan 把rowid返回tidb，然后再去tikv用rowidscan 获取表数据