共计 1450 个字符，预计需要花费 4 分钟才能阅读完成。
在理解 IndexLookUp 执行过程前，先介绍下 mysql 索引扫描的执行作为比照(此处借用网络图)，一条 SQL 执行时在存储引擎侧首先通读取索引中符合条件记录的主键(可能波及 ICP、组合索引局部列等)，而后依据主键去表中读取记录，之后将记录返回给 server 层，再由 server 层依据其余条件进行过滤后返回客户端。上述过程中索引扫描和回表操作都是在存储引擎侧实现。
IndexLookUp 算子是 tidb 通过扫描索引而后通过 rowid 回表的扫描过程，蕴含 2 个子算子 IndexScan 和 TableRowidscan, 其中 IndexLookUp 算子的执行打算 task 列为 root 示意该算子在 tidb server 侧执行，2 个子算子的 task 列为 cop[tikv]示意 coprocessor task 下推到 tikv 执行，在执行打算中算子的执行程序是先执行子算子而后返回数据给父算子，对于并列深度的子算子下面的先执行(build 端)，而后用返回后果执行另一个算子(probe 端)，但执行过程中并不严格要求所有算子都是执行完后才返回后果或者子算子全副实现后才向父算子返回后果。
官网文档中对 IndexLookUp 介绍如下：
先汇总 Build 端 TiKV 扫描上来的 RowID，再去 Probe 端上依据这些 RowID 准确地读取 TiKV 上的数据。Build 端是 IndexFullScan 或 IndexRangeScan 类型的算子，Probe 端是 TableRowIDScan 类型的算子。
始终以来因为对子算子 (IndexScan 和 TableRowidscan) 在 tikv 中执行想当然的认为索引扫描和 mysql 一样都是在存储引擎一侧实现，导致对 IndexLookUp 执行过程有谬误的意识：在 tikv 端通过索引扫描取得 rowid 后在 tikv 内应用 rowid 回表查问，最初将后果返回给 tidb server 再次过滤或返回客户端。
实际上 IndexLookUp 执行过程如下：
(1) tidb server 依据 SQL 条件结构 index scan 的 cop task, 在 tikv 侧扫描索引取得符合条件的 rowid.
(2) 扫描进去的 rowid 返回给 tidb server 进行汇总，tidb server 依据 rowid 结构 Key 和 cop task 执行回表操作
(3) tikv 应用 TableRowIDScan 回表扫描数据，而后将数据返回 tidb，执行打算中的工夫包含网络工夫。
相比于 mysql 间接在引擎内间接回表查问，tidb IndexLookUp 执行过程中要多 2 次网络交互，不可避免的会造成提早，因而网络性能、tidb server 的解决能力对 IndexLookUp 性能有肯定影响。
Tidb 有相干参数管制 indexlookup 的性能：
tidb\_index\_lookup\_size：应用 rowid 扫描表时一个批次解决的数量
tidb\_index\_lookup\_concurrency：应用 rowid 扫描表时的并发数。
测试 1：tidb\_index\_lookup\_concurrency 影响
Concurrency 由 5 降为 1 后，执行工夫由 6.15 秒增长为 26.57 秒
测试 2：tidb\_index\_lookup\_size 影响
相比拟进步并发数 tidb\_index\_lookup\_concurrency 晋升成果不是很显著
原文作者：@h5n1 发表于：2022/4/8
原文链接：https://tidb.net/blog/e09b5872
