为什么这个执行计划中Sort算子的成本这么高？

Question

Sort 运算符说它只有 100 行要排序。这怎么可能比读取 190 万行更昂贵？我一定是读错了或者误解了什么。

此外，排序运算符中的每次执行的估计行数怎么只有 100？如果 Index Seek 运算符估计 Number of Rows Per Execution 为 190 万，那么只有 100 行如何通过管道传递给 Sort 运算符？

这里是查询：

    DECLARE @PageIndex INT = 1000;
    DECLARE @PageCount INT  = 1000;

    SELECT  ID
    FROM    dbo.Table1
    WHERE DateCreated >= '2021-10-27'
            AND
        DateCreated < '2021-10-28'
    ORDER BY ID
        OFFSET @PageIndex * @PageCount ROWS FETCH NEXT @PageCount ROWS ONLY

Answer 1

排序运算符（与“前 N 排序”相对）将在返回任何行之前在其打开方法中对整个输入进行排序。

SQL 服务器估计搜索将输出 190 万行进行排序。

因此，成本计算用于排序 190 万行。

你在做

OFFSET 1000000 ROWS FETCH NEXT 1000 ROWS ONLY

排序的实际输出行将至少为 1,001,000 (maybe more in a parallel plan)，并且 TOP 运算符丢弃偏移量的前百万行，然后在收到 1000 行后停止请求行待退回。

100 的估计只是一个猜测，因为 SQL 服务器不知道编译计划时变量的值在运行时是什么。

为什么这个执行计划中Sort算子的成本这么高？

Why is the cost for the Sort operator in this execution plan so high?

sql-server

query-optimization