索引扫描何时优于大量索引查找的判断经验法则

两类操作的开销本质 #

要做判断首先得摸透两种操作的成本构成，所有选型逻辑都是从成本差推导出来的：

• Index Scan（索引扫描）：属于顺序IO读取，从B树索引根节点定位到扫描起始位置的叶节点后，沿着叶节点的双向链表连续读取数据页。不管是内存缓存命中还是磁盘读取，顺序读的单位成本都极低——内存中顺序遍历的CPU缓存命中率极高，磁盘场景下顺序读不需要频繁寻道，吞吐是随机读的上千倍。扫描的总开销只和需要遍历的索引总页数强相关，和最终匹配返回的行数没有直接关系。
• 嵌套循环连接下的多轮Index Seek（索引查找）：每一次seek都要独立走一遍完整的B树查找路径（根节点→中间分支节点→目标叶节点），属于随机IO读取。即使所有数据页都在内存里，每次B树遍历的固定寻址开销、CPU分支预测失败的开销，都远高于同数据量的顺序读。总开销≈seek次数×单次B树遍历固定成本 + 命中行的读取成本，和seek次数线性相关。

典型场景的快速估算 #

针对「21000次单值seek vs 扫描646000行覆盖索引」这类场景，用通用经验值可以直接估算：

常规OLTP场景的B树索引深度普遍为2_{4层，也就是说单次seek平均需要读取3个左右的非叶节点页才能定位到目标行。内存缓存命中时，单页顺序读的成本约为单页随机读成本的1/50}1/30；如果数据需要从磁盘读取，顺序读的单页成本仅为随机读的1/1000甚至更低。

646000行的常规宽度覆盖索引，叶节点总页数通常在数千页级别，顺序扫完的总开销大概等效于1000~3000次随机seek的成本。21000次seek的总开销大概率显著高于全索引扫描，这也是优化器默认选择扫描路径的核心原因，不是优化器判断失误。

影响选型边界的核心因素（除行数外） #

除了两边的行数比值，以下几个因素会直接移动盈亏平衡点：

• 索引冗余列占比：如果索引中包含大量查询不需要的长列（比如长字符串、二进制大字段），扫描的开销会线性上升——无关列越多，单数据页能存储的有效索引行越少，扫描需要读取的总页数越多。而Index Seek的开销几乎不受冗余列影响，因为seek只需要定位到目标行后读取所需列，不需要遍历无关行的内容。
• 数据缓存命中率：如果待扫描的索引大部分不在内存中，顺序扫描的优势会进一步放大；反过来如果所有seek的目标行都是业务热点数据、已经常驻内存，seek的随机IO开销会大幅降低，盈亏平衡点会向seek侧偏移。
• 匹配值的分布特征：如果所有seek要匹配的行在索引叶节点上是连续聚集的，多次seek可以退化成连续范围扫描，开销会骤降；如果匹配行完全离散分布在索引的不同数据页上，seek的随机开销会拉到最高。
• 后续操作的排序需求：索引扫描天然按索引键顺序输出结果，如果后续算子需要按索引键排序，可以直接省掉排序开销；嵌套循环seek的输出顺序和外层输入一致，和索引键顺序无关，如果后续需要排序还要额外支付排序成本。
• 是否需要回表：如果索引不覆盖查询列，每次seek后还要做Key Lookup（键查找）回表读数据，seek的盈亏平衡点会大幅降低——通常超过1000次带回表的seek，性能就会不如全索引扫描。

无需压测的快速判断经验法则 #

日常场景下不需要每次都加连接提示做基准对比，按以下阈值判断即可：

• 当需要匹配的行数超过索引总行数的**1%~5%**区间时，覆盖索引扫描的性能几乎一定优于多轮seek；如果索引包含大量冗余长列，这个阈值可以放宽到10%左右。
• 当需要匹配的行数低于索引总行数的0.1%时，不管什么场景，seek的性能都会更好。
• 匹配行数占比在0.1%~5%的区间属于边界场景，才值得花时间强制路径做性能对比，不在这个区间的话直接采信优化器的成本选择即可，没必要额外调优。

内容的提问来源于stack exchange，提问作者DJL