ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C) 不使用 (A,B,C) 上的索引

Question

ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C) 不使用 (A,B,C) 上的索引

Vla*_*nov 15 sql-server-2008 sql-server sql-server-2014

考虑这两个函数：

ROW_NUMBER() OVER (PARTITION BY A,B ORDER BY C)

ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C)

Run Code Online (Sandbox Code Playgroud)

据我了解，它们产生完全相同的结果。换句话说，您在PARTITION BY子句中列出列的顺序无关紧要。

如果有一个索引，(A,B,C)我希望优化器在两个变体中都使用这个索引。

但是，令人惊讶的是，优化器决定在第二个变体中进行额外的显式排序。

我在 SQL Server 2008 Standard 和 SQL Server 2014 Express 上见过它。

这是我用来重现它的完整脚本。

使用OPTION (QUERYTRACEON 9481)和使用旧的和新的基数估计器OPTION (QUERYTRACEON 2312)。

设置表、索引、样本数据

CREATE TABLE [dbo].[T](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [A] [int] NOT NULL,
    [B] [int] NOT NULL,
    [C] [int] NOT NULL,
    CONSTRAINT [PK_T] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, 
IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS = ON, 
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [IX_ABC] ON [dbo].[T]
(
    [A] ASC,
    [B] ASC,
    [C] ASC
)WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, 
SORT_IN_TEMPDB = OFF, 
DROP_EXISTING = OFF, 
ONLINE = OFF, 
ALLOW_ROW_LOCKS = ON, 
ALLOW_PAGE_LOCKS = ON)
GO

INSERT INTO [dbo].[T] ([A],[B],[C]) VALUES
(10, 20, 30),
(10, 21, 31),
(10, 21, 32),
(10, 21, 33),
(11, 20, 34),
(11, 21, 35),
(11, 21, 36),
(12, 20, 37),
(12, 21, 38),
(13, 21, 39);

Run Code Online (Sandbox Code Playgroud)

查询

SELECT -- AB
    ID,A,B,C
    ,ROW_NUMBER() OVER (PARTITION BY A,B ORDER BY C) AS rnAB
FROM T
ORDER BY C
OPTION(RECOMPILE);

SELECT -- BA
    ID,A,B,C
    ,ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C) AS rnBA
FROM T
ORDER BY C
OPTION(RECOMPILE);

SELECT -- both
    ID,A,B,C
    ,ROW_NUMBER() OVER (PARTITION BY A,B ORDER BY C) AS rnAB
    ,ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C) AS rnBA
FROM T
ORDER BY C
OPTION(RECOMPILE);

Run Code Online (Sandbox Code Playgroud)

执行计划

按 A、B 分区

B,A分区

两个都

如您所见，第二个计划有一个额外的排序。它由 B、A、C 订购。显然，优化器不够聪明，无法意识到这与数据PARTITION BY B,A相同PARTITION BY A,B并重新排序数据。

有趣的是，第三个查询包含的两个变体，ROW_NUMBER并且没有额外的排序！该计划与第一个查询相同。（序列项目在额外列的输出列表中有额外的表达式，但没有额外的排序）。因此，在这种更复杂的情况下，优化器似乎足够聪明，可以意识到这PARTITION BY B,A与PARTITION BY A,B.

在第一个和第三个查询中，Index Scan 操作符具有 Ordered:True 属性，在第二个查询中它是 False。

更有趣的是，如果我像这样重写第三个查询（交换两列）：

SELECT -- both
    ID,A,B,C
    ,ROW_NUMBER() OVER (PARTITION BY B,A ORDER BY C) AS rnBA
    ,ROW_NUMBER() OVER (PARTITION BY A,B ORDER BY C) AS rnAB
FROM T
ORDER BY C
OPTION(RECOMPILE);

Run Code Online (Sandbox Code Playgroud)

然后额外的排序再次出现！

有人可以解释一下吗？这里的优化器发生了什么？

Answer 1

Vla*_*nov 5

似乎对于“优化器中发生了什么”这个问题没有一个好的明确的“答案”，除非您是它的开发人员并且了解其内部结构。

\n\n

我将在这里整理评论。

\n\n

总体来说，似乎称其为bug未免太苛刻了，因为查询的最终结果是正确的。在某些情况下，执行计划根本不是最佳的。ypercube\xe1\xb5\x80\xe1\xb4\xb9，马丁·史密斯和亚伦·伯特兰称之为“错过的优化”。

\n\n

\n
看起来像GROUP BY a,b并GROUP BY b,a产生相同的计划\n但PARTITION BY不能使用相同的转换
\n
\n
还存在其他缺失的优化，其中具有相同窗口规范的窗口函数如果在选择列表中被具有不同规范的窗口函数分隔，则可以具有额外的排序操作。
\n
\n
是的，这似乎是另一个错过的优化，而且有很多这样的优化。优化器是人类编写的，并不完美
\n

\n\n

有一篇有点相关的文章降序索引。Itzik Ben-Gan 的索引排序、并行性和排名计算。其中 Itzik 讨论了降序索引，并给出了索引定义的方向如何影响带有分区的窗口函数的示例。他展示了查询和生成计划的示例，其中ROW_NUMBER包含优化器可以避免的额外排序运算符。

\n\n

对我来说，实际结果是牢记优化器的这种特性。在窗口函数中使用时，PARTITION BY始终尝试将列出列的顺序PARTITION BY与它们在索引中列出的顺序相匹配。尽管应该没关系。

\n\n

这种预防措施的另一方面是当您检查索引并决定交换索引定义中的某些列时。请注意，您可能会无意中影响一些看似不应受到影响的现有查询。这实际上就是我注意到优化器这一特性的方式。

\n\n

如果不这样做，优化器可能无法充分利用索引的潜力。即使优化器确实选择了最佳计划，这种计划也可能会因对查询进行最轻微的无害更改（例如更改语句中列的顺序）而变得不太理想SELECT。

\n

归档时间：	9 年，3 月前
查看次数：	9416 次
最近记录：	8 年，8 月前