标签: table-spool

我有一个疑问：

select * from Aview where field=20
order by id desc

这将在大约 1 秒内从视图中返回 2700 行。

在查询中添加“top 20”使 MSSQL 在 43 秒内返回！

这是一个很难重现的问题，重建统计数据可以修复该问题几天，但随后又回来了。

我使用 SQL 已经有几十年了，我从未见过添加“top”导致时间增加的情况。

查看执行计划，如果执行前 20 条，它似乎正在执行 9.6 亿行的惰性假脱机操作，但如果不执行，则不会执行。

我正在 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 中需要 …