考虑这个物化视图:
CREATE VIEW [vwPlaySequence] WITH SCHEMABINDING
AS
SELECT
p.SiteIDNumber,
dbo.ToUnsignedInt(p.SequenceNumber) AS PlayID,
p.SequenceNumber
FROM dbo.Play p
GO
CREATE UNIQUE CLUSTERED INDEX
PK_vwPlaySequence ON [vwPlaySequence]
(
[PlayID],
[SiteIDNumber],
[SequenceNumber]
)
GO
基表在SequenceNumber上有一个聚簇索引。
基表上的以下查询在4秒内执行1.6亿行:
select SiteIDNumber, min(SequenceNumber), max(SequenceNumber) from Play
group by SiteIDNumber
这是执行计划:
这是视图在46秒内执行的相同查询:
select SiteIDNumber, min(SequenceNumber), max(SequenceNumber) from vwPlaySequence
group by SiteIDNumber
其执行计划:
我没有看到这些执行计划中的内容会在运行时间产生如此巨大的差异。我使用相同的结果多次运行这两个查询。
答案 0 :(得分:3)
两个查询都使用该视图。一个是平行的,不是。您说在两个查询中添加OPTION (MAXDOP 1)
会使所有差异消失。这意味着并行性可以解释所有差异。
没有逻辑原因SQL Server必须在其中一个案例中选择一个串行计划。这可能是一个错误或已知的限制。我通过索引视图匹配遇到了许多限制和奇怪的行为。从那个意义上讲,我只是有点意外。
既然已经解释了差异,那该怎么做呢?
OPTION (QUERYTRACEON 8649) --set parallelism cost to zero
。这是一个无证的痕迹标志,被一些领先的专家认为是安全的。我也认为这是安全的。WITH (NOEXPAND)
从视图中进行选择。这会绕过视图匹配,并希望SQL Server能够找到并行计划。首选选项(2)。