sql-server - 为什么索引查找比索引扫描更昂贵

Question

我有一个关于索引扫描/查找的基本问题。当需要获取大量行时，索引扫描非常有效。也就是说索引扫描成本与返回的行数成反比。行数越少，查询的成本就越高，因为它必须扫描所有页面，从而导致更多 IO。

我已经搜索了查找比扫描更昂贵的原因，但我无法找到查找变得昂贵的原因。

我感到困惑的是索引查找。为什么随着返回的行数增多，索引查找会变得昂贵。索引查找总是比扫描更快、更高效，因为它直接触及包含行的页面。因此，即使返回大量行，索引查找也应该始终比索引扫描更有效。但这并没有发生。我想确切地知道为什么在某些时候搜索变得昂贵。

select id,name,col1,col2
from TableA   -- Will result in index scan. Table has 10000 rows with clustered index on ID column. Query has covering index.

select id,name,col1,col2
where ID between 1 and 10
from TableA   -- Optimizer Will use index Seek.

现在为什么当强制索引查找时下面的查询会变得昂贵 -

select id,name,col1,col2
from TableA with (forceseek)

Answer 1

聚集索引查找比索引扫描昂贵的原因是索引查找开始从根节点到叶节点读取 B 树。这涉及读取叶节点内的索引和页面。因此会导致更多的 IO。因此，当选择性较低时，优化器会选择索引扫描而不是索引查找。只有当返回的记录不超过 2% 到 3% 时，Seek 才比较好。