显示估计的执行计划会生成CXPACKET，PAGELATCH_SH和LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待

我在4个vCPU VM运行Microsoft SQL Server 2016 SP2-CU6（13.0.5292.0）与max degree of parallelism设置为2和cost threshold for parallelism设置为50。

早晨，当尝试显示SELECT TOP 100查询的估计执行计划时，我遇到了大量的等待，渲染估计计划的操作需要花费几分钟，通常是5到7分钟。同样，这不是查询的实际执行，这只是显示“ 估计的执行计划”的过程。

sp_WhoIsActive将显示PAGEIOLATCH_SH等待或LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待，当我在操作期间运行Paul Randal的WaitingTasks.sql脚本时，它将显示CXPACKET等待，而工作线程显示PAGEIOLATCH_SH等待：

*资源描述字段= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

工作线程看起来是将整个stats表都放入内存中（因为从Paul Randal的查询中显示的那些页号以及后续页号都指向该stats表的集群键）。一旦计划恢复，即使在stats剩余的各种记录（我认为由于类似查询的查找操作而将其拉出）的情况​​下，大部分缓存都从高速缓存中消失之后，一天中的剩余时间基本上都是瞬时的。

如果查询实际上是使用SCAN运算符的计划执行的，我会期望出现这种初始行为，但是为什么在评估执行计划时才这样做（如上面链接的计划所示），以达到SEEK运算符呢？我该怎么办（除了在办公时间之前运行此语句，以便适当地缓存我的数据），以帮助提高此处的性能？我假设一对覆盖索引将是有益的，但是它们真的可以保证行为的任何改变吗？我必须在这里在一些存储和维护窗口限制内工作，并且查询本身是从供应商解决方案生成的，因此，此时欢迎任何其他建议（除了更好的索引编制）。

似乎是您要求的实际执行计划触发了统计信息更新。既然您提到过这种情况是在早晨发生的，那么我想像有一个通宵的过程，需要对涉及的表进行很多修改吗？

因此，SQL Server使用统计信息来创建计划，达到修改阈值并作为操作的一部分执行自动统计信息更新。

在您共享的估算计划的XML中，我看到了今天早上这些统计数据的更新日期：

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

如果这些表非常大，忙碌（似乎可能基于采样百分比），那么统计信息更新会花费很多精力也就不足为奇了。

当我在SSMS中看到很长的计划时间时，按可能性顺序是以下之一：

1. 查询优化器决定需要创建或更新统计信息。
2. 估计计划的大小非常大（例如，> 10 MB），SSMS花费很长时间才能显示它。
3. 实际上，由于CPU使用率，查询编译本身需要花费很长时间才能找到足够好的计划。
4. 服务器处于极端胁迫状态。例如，我可能必须等待网关可用。
5. 各种错误导致编译时间极长。

对于您的情况，答案几乎可以肯定是SQL Server正在更新或创建统计信息。有一些线索：查询计划的大小很小，查询计划相对简单且成本较低，并且编译CPU明显低于编译时间：

新撰稿人Josh Darnell还指出了XML上一次统计更新的良好线索。

SQL Server 2019引入了新的等待类型WAIT_ON_SYNC_STATISTICS_REFRESH，用于查询正在等待统计信息更新的时间。在该版本上诊断该问题要容易得多。在那之前，您只需要依靠间接技术即可。

解决方法包括在维护期间更新统计信息或为数据库启用“自动更新统计信息异步”。在更改之前，请先了解该选项的全部内容。查询计划将在统计信息更新之前而不是统计信息更新之后创建。对于某些工作负载而言，这可能是一个巨大的胜利。对于其他人来说，弊大于利。