performance - 为什么这是索引扫描而不是索引搜索？

Question

这是查询:

SELECT      top 100 a.LocationId, b.SearchQuery, b.SearchRank
FROM        dbo.Locations a
INNER JOIN  dbo.LocationCache b ON a.LocationId = b.LocationId
WHERE       a.CountryId = 2
AND         a.Type = 7

位置索引:

PK_位置:

LocationId

IX_Locations_CountryId_Type:

CountryId, Type

LocationCache 索引:

PK_LocationCache:

LocationId

IX_LocationCache_LocationId_SearchQuery_SearchRank:

LocationId, SearchQuery, SearchRank

执行计划:



所以它正在做 索引搜索 在 Locations 上，使用覆盖索引，很酷。

但是为什么它在做 索引扫描在 LocationCache 覆盖索引上？

该覆盖索引在索引中有 LocationId、SearchQuery、SearchRank(不是“包含列”)。

将鼠标悬停在索引扫描上:



此查询需要进入由 SQL Server FTS 目录提供的索引 View ，由自动完成插件使用，因此需要 100% 优化。

目前，上述查询需要 3 秒。它应该 < 0。

有任何想法吗？

Answer 1

它使用索引扫描主要是因为它还使用了合并连接。 Merge Join 运算符需要两个输入流，它们都按照与 Join 条件兼容的顺序排序。

它使用 Merge Join 运算符来实现您的 INNER JOIN，因为它认为这将比更典型的 Nested Loop Join 运算符更快。它可能是正确的(通常是这样)，通过使用它选择的两个索引，它具有根据您的连接条件(LocationID)预先排序的输入流。当输入流像这样预先排序时，合并连接几乎总是比其他两个(循环和哈希连接)快。

缺点是您已经注意到:它似乎正在扫描整个索引，那么如果它正在读取这么多可能永远不会使用的记录，那怎么能更快呢？答案是扫描(因为它们的顺序性质)可以读取任何地方的记录数是搜索次数的 10 到 100 倍/秒。

现在 Seeks 通常会获胜，因为它们是有选择性的:它们只获取您要求的行，而 Scans 是非选择性的:它们必须返回范围内的每一行。但是因为 Scans 具有更高的读取率，所以只要 Discarded Rows 与 Matching Rows 的比率低于 Scan rows/sec VS 的比率，它们就可以经常击败 Seeks。搜索行/秒。

问题？

好的，我被要求进一步解释最后一句话:

“Discarded Row”是 Scan 读取的行(因为它必须读取索引中的所有内容)，但这将被 Merge Join 运算符拒绝，因为它在另一侧没有匹配项，可能是因为WHERE 子句条件已将其排除。

“匹配行”是它读取的与合并连接中的某些内容实际匹配的行。如果 Scan 被 Seek 替换，这些行将被 Seek 读取。

您可以通过查看查询计划中的统计信息来了解其中的内容。看到索引扫描左侧那个巨大的粗箭头了吗？这表示优化器认为它将通过 Scan 读取的行数。您发布的索引扫描的统计信息框显示返回的实际行数约为 5.4M (5,394,402)。这等于:

TotalScanRows = (MatchingRows + DiscardedRows)

(无论如何，在我看来)。要获得匹配行，请查看 Merge Join 运算符报告的“实际行”(您可能需要去掉 TOP 100 才能准确获得)。知道这一点后，您可以通过以下方式获取 Discarded 行:

DiscardedRows = (TotalScanRows - MatchingRows)

现在您可以计算比率。