查询优化。嵌套循环答案

【问题标题】：Query Optimization. Nested Loops查询优化。嵌套循环
【发布时间】：2020-03-08 01:22:06
【问题描述】：

我尝试了解查询优化的工作原理。我执行了以下查询：

查询 #1

SELECT * 
FROM Product 
WHERE price < 50000 
ORDER BY id DESC

查询 #2

SELECT * 
FROM Product 
WHERE price > 50000 
ORDER BY id DESC

所以在每个查询的执行计划中，我注意到优化器对第一个查询使用聚集索引扫描，但是对于第二个查询，首先使用排序然后嵌套循环。

这些执行计划背后的逻辑是什么？

【问题讨论】：

这两个查询是相同的，所以我希望它们具有相同的执行计划。此外，“嵌套循环”通常指的是joins，并且两个查询都没有任何joins（假设Product 是一个表而不是一个视图）。
对于相同的查询，可能是在执行之间更新了统计信息，导致不同的计划。
我更正了查询中的错误
他们不一样。它们是比较的两个方面，统计数据可能会说第一个的返回数据比第二个少得多。

【解决方案1】：

这些执行计划背后的逻辑是什么？

它试图找到使用索引及其统计信息执行查询的最快方法。

在上面的例子中。如果你有 100 亿个价格（假设 1 到 100 亿），第一个要求前 50k，第二个要求 100 亿减去 50k 返回值。大不同。

每个索引都保存一个值分布的统计信息，SQL Server 使用它来估计特定操作方式的成本。然后它会选择最有效的。

【讨论】：

【解决方案2】：

假设id 上的clustered index 和price 上的secondary index，让我们考虑如何执行这种类型的查询：

要么：首先检索正确的行子集（对price 索引使用范围扫描），然后在id DESC 上对结果进行排序。
或者：以反向聚集索引顺序（与id DESC相同）扫描整个表，并像您一样过滤掉不合适的行。扫描会产生正确排序的结果，并且删除某些行不会影响顺序，因此不需要单独排序。

优化器选择这两个中的哪一个取决于检索行子集然后排序与检索所有行和过滤的相对成本，TomTom 已经为此做了一些good points。

现在让我们考虑一下为什么在情况（1）中需要嵌套循环......

price 上的索引只能用于检索 price（因为它被显式索引）和id（隐式包含在每个二级索引中）。

因此，如果您要求任何附加字段（就像您通过 * 所做的那样），则必须从聚集索引中查找它们。换句话说，构建完整的行不仅需要一次，而且需要两次物理检索（首先从二级索引然后聚集索引），因此需要嵌套循环。

然后执行如下：

要避免嵌套循环，请尝试：

SELECT id, price
FROM Product 
WHERE price > 50000 
ORDER BY id DESC

由于pricecovers上的索引同时有price（显式）和id（隐式），所以单独可以满足查询，不需要聚集索引查找。

【讨论】：