连接2个视图时查询速度极慢

Question

首先，我将说我不是一个DBA，只是一个正在试图用下面的查询解决性能问题的开发人员。

 SELECT
        OCCoverID as StaffID, FullName, SUM(OCWeight) AS Num
    FROM vuOCStaffAbsentExpandedMini
        INNER JOIN vuStaff ON OCCoverID = StaffID
    WHERE
        SADate = '2019-10-4'
        AND MIDent = 506
        AND SASupplyID IS NULL
        AND CoverStaffSupplyID IS NULL
        AND StaffMIDent <> 1
    GROUP BY
        OCCoverID, FullName

每次执行大约需要1分钟，我们已经检查了(我们认为)所有所需的索引，通过索引调谐器运行它，并且仍然存在相同的问题。下面是它创建的实际计划。

任何帮助都将不胜感激，我们正在使用sql server 2012 express。

https://www.brentozar.com/pastetheplan/?id=HJgOtXHur

Answer 1

您有一个为嵌套循环运算符提供信息的性能假脱机(不应用)

...with估计值很低。

现在，对于顶部(外部)输入中的每个值，表假脱机将产生一个重新绑定。在非应用嵌套循环联接上，性能线轴不可能进行重绕。

在第一个循环迭代期间，只填充一次...The懒表假脱机。对于连接的每一个后续迭代，假脱机都会对其内容进行回绕。对于嵌套循环联接，联接的内部是一组静态行，因为连接谓词位于联接本身。因此，静态内部行集可以通过假脱机多次缓存和重用。嵌套循环连接性能线轴从不重新绑定..。

资料来源: Paul关于嵌套和性能

估计数偏低的原因是实际情况如下：

您可以通过将两个输入(计算标量&流聚合)相乘来验证假脱机输出的高行数。

515 728 (外部输入) * 168 (内部输入)= 86 642 304

解决方案

要解决的第一件事是修正为什么预算如此之低。

您可以尝试更新视图中引用的表的统计信息。

但是您似乎在dbo.TblOnCall和输入假脱机操作符的表之间做了一个D9比较。

这也可以在从假脱机获取数据的NL操作符上看到。

(EXPR 1137 =外部输入，UNION =内部输入)。

For长期解决方案，

我将修复这个LIKE比较和任何其他将严重影响您的估计的部分。

我们必须看到视图，才能给出最正确的查询建议。

For是一个临时的快速修复程序，您可以使用跟踪标志或查询提示禁用假脱机。

性能线轴可以使用记录较少的跟踪标志8690或Server 2016或更高版本上的文档查询提示NO_PERFORMANCE_SPOOL来禁用。来源

实现此操作的一个示例是运行

DBCC TRACEON(8690,-1) (将在实例重新启动时删除)

或者更好的方法是使用OPTION(QUERYTRACEON 8690)运行查询

 SELECT
        OCCoverID as StaffID, FullName, SUM(OCWeight) AS Num
    FROM vuOCStaffAbsentExpandedMini
        INNER JOIN vuStaff ON OCCoverID = StaffID
    WHERE
        SADate = '2019-10-4'
        AND MIDent = 506
        AND SASupplyID IS NULL
        AND CoverStaffSupplyID IS NULL
        AND StaffMIDent <> 1
    GROUP BY
        OCCoverID, FullName
OPTION(QUERYTRACEON 8690);