sql-server - 使用奇怪的查询优化器行为连接 SQL Server 中的 View

Question

我有一个复杂的 View ，用于提取主键列表，这些主键指示表中已在两个时间点之间修改的行。

此 View 必须查询 13 个相关表并查看更改日志表以确定实体是否“脏”。

即使发生了这一切，还是做一个简单的查询:

select * from vwDirtyEntities;

只需 2 秒。

但是，如果我将其更改为

select
    e.Name
from 
    Entities e 
         inner join vwDirtyEntities de
             on e.Entity_ID = de.Entity_ID

这需要 1.5 分钟。

但是，如果我这样做:

declare @dirtyEntities table
(
    Entity_id uniqueidentifier;
)

insert into @dirtyEntities 
   select * from vwDirtyEntities;


select
   e.Name
from 
    Entities e 
        inner join @dirtyEntities de
           on e.Entity_ID = de.Entity_ID

我只用了 2 秒就得到了相同的结果。

这让我相信 SQLServer 在连接到实体时正在评估每行的 View ，而不是构建一个涉及将上面的单个内部连接连接到 View 中其他连接的查询计划。

请注意，我想加入此 View 中的完整结果集，因为它只过滤掉我内部想要的键。

我知道我可以将其变成物化 View ，但这将涉及绑定(bind) View 及其依赖项的架构，并且我不喜欢维护索引会导致的开销(此 View 仅针对导出进行查询，而有对基础表的写入次数要多得多)。

那么，除了使用表变量来缓存 View 结果之外，还有什么方法可以告诉 SQL Server 在评估联接时缓存 View 呢？我尝试更改加入顺序(从 View 中选择并针对实体加入)，但这没有任何区别。

View 本身也非常高效，并且没有优化的空间。

Answer 1

View 并没有什么神奇之处。这是一个可扩展的宏。优化器决定何时 JOINed 将 View 扩展到主查询。

我将解决您帖子中的其他要点:

• 您已排除索引 View 。 View 在被索引时只能是离散实体

• SQL Server 永远不会自行执行 RBAR 查询。只有开发人员才能编写循环。

• 没有缓存的概念:每个查询都使用最新数据，除非您使用临时表

• 您坚持使用您认为非常有效的 View 。但不知道优化器如何处理 View ，它有13表

• SQL 是声明式的:连接顺序通常并不重要

• 许多认真的数据库开发人员不使用 View ，因为这样的限制:它们不可重用，因为它们是宏

编辑，另一种可能性。 Predicate pushing在 SQL Server 2005 上。也就是说，SQL Server 无法将 JOIN 条件“更深”插入 View 中。