当查询优化器计算执行计划的成本时，您能否预期该计划会根据可用资源量而有所不同？
采取以下情况：
- 您有一个运行 SQL Server 2008 R2 的 VMware 虚拟机，具有 32GB RAM，8 个 CPU 内核连接到 SAN。有 7 个 VM 共享主机箱。
- 您发现 CPU 使用率经常达到 130% 的峰值，因此您将大部分 VM 移出主机，仅保留原始 7 个 VM 中的 3 个，包括 SQL Server 框。
- 您会立即发现，由于有更多的 CPU 可用空间，实际性能变慢了。您可以看到来宾的 CPU 利用率比之前可以达到的 30% 高得多（因为有更多的 CPU 资源可供使用）。尽管如此，该应用程序的用户还是发现性能明显下降。
我对 SQL VM 为什么在有更多 CPU 资源可用时执行速度变慢的解释是，过程缓存包含在 CPU 可用性较低的环境下计算/优化的计划。当额外资源可用时，过程缓存将提供次优计划，这些计划可能执行得不太好。
这有意义吗？几周前我们遇到了这种情况，一旦我们停止了主机上的 CPU 抖动，我们就收到了很多关于性能的抱怨。我运行了 dbcc freeprocache，此后性能似乎有所提高 - 或者用户已经习惯了。
想法？谢谢
首先，一些背景信息
到目前为止（直到 SQL Server 2014）查询优化器只会考虑几件事：
CPU 内核：从关联掩码分配给 SQL Server 的内核数决定了创建并行计划的效率。例如，在具有 4 个内核的系统上，当切换到并行计划时您可以获得 4 倍的加速，而具有 2 个内核的系统只能提高一倍。因此，核心数会影响计划的选择。不幸的是，并非每个查询都可以随核心数线性扩展，但优化器会相信它可以。这意味着在拥有超过 12-16 个内核的机器上，获得更多的并行性实际上会减慢查询速度。不考虑CPU的速度，只考虑核心数。
可用内存：制定计划时，会考虑可用内存量。这决定了哈希连接、排序空间和其他内存密集型操作等策略。这里的错误估计是非常危险的，会导致性能不佳。特别是如果您高估了可用于哈希连接的内存并且不得不溢出到
tempdb.您的具体情况
如果不对您的系统进行测量，即使不是不可能，也很难准确了解您的场景中发生了什么。有太多变量可能同时发生变化。可能只是环境中发生了其他变化。任何诊断都是纯粹的猜测，真正的 DBA 工作是一门科学，而不是猜测中的附庸风雅的练习。
您需要收集以下内容以获取知识。