相关疑难解决方法(0)

我在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 分钟的范围内。同样，这不是查询的实际执行，这只是显示Estimated Execution Plan 的过程。

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 运算符？我可以做些什么（除了在办公时间之前运行此语句以便适当缓存我的数据）来帮助提高性能？我假设一对覆盖索引将是有益的，但它们真的能保证行为的任何变化吗？我必须在此处处理一些存储和维护窗口限制，并且查询本身是从供应商解决方案生成的，因此此时欢迎任何其他建议（除了更好的索引）。