当从带有外部参数化“ where”子句的视图中调用时，窗口函数会导致糟糕的执行计划

很久以前，我遇到了这个问题，我找到了适合自己的解决方法，却忘了它。

但是现在在SO上存在这个问题，所以我愿意提出这个问题。

有一个视图以非常简单的方式（订单+订单行）连接了几个表。

当查询不带where子句的视图时，该视图将返回几百万行。
但是，没有人会这样称呼它。通常的查询是

select * from that_nasty_view where order_number = 123456;

这将返回5m中的10条记录。

重要的是：该视图包含一个窗口函数，该窗口函数rank()完全由始终查询该视图的字段划分：

rank() over (partition by order_number order by detail_line_number)

现在，如果使用查询字符串中的文字参数查询此视图（完全如上所示），它将立即返回行。执行计划很好：

• 使用on的索引在两个表上进行索引查找order_number（返回10行）。
• 在返回的微小结果上计算窗口。
• 选择。

但是，当以参数化方式调用视图时，情况会变得很糟：

• Index scan在所有表上忽略索引。返回5m行。
• 巨大的加入。
• 计算所有partitions上的窗口（约50万个窗口）。
• Filter 从5m中取出10行。
• 选择

在涉及参数的所有情况下都会发生这种情况。可以是SSMS：

declare @order_number int = 123456;
select * from that_nasty_view where order_number = @order_number;

它可以是ODBC客户端，例如Excel：

select * from that_nasty_view where order_number = ?

也可以是使用参数而不使用sql串联的任何其他客户端。

如果将窗口函数从视图中删除，则无论是否使用参数查询，它都能完美快速地运行。

我的解决方法是删除有问题的功能，然后在稍后阶段重新应用它。

但是，有什么用呢？这真的是SQL Server 2008如何处理窗口功能的错误吗？

这似乎是一个长期存在的问题，它以一种或另一种形式重新铺装，并在SQL Server 2012中仍然存在。

一些讨论它的帖子是

• 性能调整101-2005
• 带有序列投影的计划回归-2008 R2 @Paul White
• 公用表表达式（CTE），窗口函数和视图-2012 @Jonathan Kehayias
• 窗口功能和视图的问题

直到（包括2012年）的所有当前版本的SQL Server都不能将分区组上的筛选器推过参数化谓词的序列项目的序列项目，除非option(recompile)已使用（如果使用2008+）。

recompile提示的替代方法是重写查询，以使用由@ a1ex07建议的参数化嵌入式TVF。

我尝试用表值udf替换视图。这样，它将首先过滤记录，然后再应用窗口功能。此函数可以接受表参数，因此您可以将多个参数传递order_number给它