不可预测的缓慢和表假脱机（延迟读取）

Question

我正在 Stackoverflow 数据库上进行测试，以找出 SQL Server 不建议在执行计划中使用索引的可能情况，但是如果我们引入索引，它将有很大帮助！

对于 Group by、Order by Clause 和聚合函数（计数函数 - 表的最小副本）来说，这很容易吗？我编写了一个随机查询，其中我知道引入支持性索引肯定会有所帮助，但是缺少索引建议将仅在连接条件上而不是在 order by 子句上。

查询如下：

select top 100 Location from Users U join Badges B
on B.UserId = U.Id
order by Location desc

引入以下索引来提高性能：

create index Location on Users(Location)
go
create index UsersId on Badges(UserId)
go

优化器按照上述查询的预期使用索引：

逻辑读取和时间统计如下：

现在，我想测试仅在位置列上的用户表上建立索引并且在徽章（UserId）表上没有索引的情况下的性能，这里性能变得很糟糕（需要大约 7 分钟）：

逻辑读取和时间统计如下：

用户表上的索引被大量使用，从执行计划和逻辑读取可以明显看出，但是执行聚集索引扫描和表假脱机（惰性假脱机）会导致大部分问题。

以上所有测试均在 SQL Server 2019 上以 SQL Server 2016 兼容模式（130）进行。

如果有人可以就根本问题提供建议，将会有很大帮助。

这里还要注意一点，当这两个表中的任何一个上都没有非聚集支持索引时，相同的查询会在 9 秒内完成。下面是执行计划：

逻辑读取和时间统计：

出于测试目的，我将兼容性级别更改为 2019(150)，令我惊讶的是 - 之前的相同查询仅在用户（位置）表上有索引，而不在徽章表上有索引，在 2 秒内完成，而在 SQL Server 2016 中需要 7 分钟兼容（130）模式：

逻辑统计和时间统计：

在2019兼容模式下，Parallelism之前的所有算子都是批处理模式。

这方面的任何输入都将帮助我理解这种行为。

Answer 1

由于使用子句设置了行目标，优化器会选择带有惰性假脱机的计划TOP。

\n

select top 100 Location from Users U join Badges B\non B.UserId = U.Id\norder by Location desc\n

您要求的是前 100 行\xe2\x80\x94，而不是完整的集合\xe2\x80\x94，因此优化器会尝试找到一个快速返回 100 行的计划，而不是在最快的时间内返回所有匹配项的计划。

\n

优化器的推理基于统计数据和建模假设，这可能会出错，就像这里一样。

\n

惰性表假脱机是一个性能假脱机。

\n

行目标和性能假脱机都将计入显示为最便宜的计划的估计成本中。

\n

您可以使用查询提示禁用性能假脱机：

\n

NO_PERFORMANCE_SPOOL\n

您可以使用查询提示禁用行目标逻辑：

\n

USE HINT (\'DISABLE_OPTIMIZER_ROWGOAL\')\n

两者都会给你一个更像你最后展示的哈希和前n排序的计划，但当兼容性设置为130时没有批处理模式。

\n

顺便说一句，惰性假脱机计划的性能非常依赖于您的硬件，尤其是内存和tempdb性能。我的笔记本电脑上的典型执行只需 6.5 秒：

\n

如果没有非聚集索引，它运行 6.9 秒：

\n

在 Microsoft SQL Server 2019 CU15 上执行。最大内存设置为 4GB，12 个可用逻辑处理器。

\n