SQL Server 2012 row_number ASC DESC 性能

Question

在 SQL Server 2012 版本 11.0.5058 中，我有这样的查询

SELECT TOP 30 
    row_number() OVER (ORDER BY SequentialNumber ASC) AS [row_number], 
    o.Oid, StopAzioni 
FROM 
    tmpTestPerf O 
INNER JOIN
    Stati s on O.Stato = s.Oid
WHERE 
    StopAzioni = 0

• 当我使用ORDER BY SequentialNumber ASC 时需要 400 毫秒
• 当我在 row_number 函数中使用 ORDER BY DESC 时，只需要 2 毫秒

（这是在测试环境中，在生产环境中是 7000，7 秒对 15 毫秒！）

分析执行计划，我发现两个查询都是一样的。有趣的区别在于，在较慢的情况下，它适用于由stopazioni = 0 条件过滤的所有行，117k 行

在更快的情况下它只使用 53 行

tmpTestPerf 查询上有一个主键，序号列上有一个索引 ASC 键。

如何解释？

问候。 丹尼尔

这是 tmpTestPerfQuery 和 Stati 查询及其索引的脚本

CREATE TABLE [dbo].[tmpTestPerf]
(
    [Oid] [uniqueidentifier] NOT NULL,
    [SequentialNumber] [bigint] NOT NULL,
    [Anagrafica] [uniqueidentifier] NULL,
    [Stato] [uniqueidentifier] NULL,

    CONSTRAINT [PK_tmpTestPerf] 
      PRIMARY KEY CLUSTERED ([Oid] ASC)
)

CREATE NONCLUSTERED INDEX [IX_2] 
   ON [dbo].[tmpTestPerf]([SequentialNumber] ASC)

CREATE TABLE [dbo].[Stati]
(
    [Oid] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
    [Descrizione] [nvarchar](100) NULL,
    [StopAzioni] [bit] NOT NULL

    CONSTRAINT [PK_Stati] 
      PRIMARY KEY CLUSTERED ([Oid] ASC)
) ON [PRIMARY]

CREATE NONCLUSTERED INDEX [iStopAzioni_Stati] 
   ON [dbo].[Stati]([StopAzioni] ASC)
GO

Answer 1

查询计划并不完全相同。

选择索引扫描运算符。

按 F4 查看属性并查看扫描方向。

当您升序时，扫描方向为正向，而当您降序时，扫描方向为后退。

之所以存在行数差异，是因为在索引中向后扫描时只需 53 行即可找到 30 行，而在索引中向前扫描时需要 117k 行才能找到 30 个匹配行。

请注意，如果主查询中没有 order by 子句，则无法保证您将从查询中获得 30 行。在这种情况下，它恰好是前三十个或后三十个，具体取决于 row_number() 中使用的顺序。