sql-server - 在新创建的 View 上获得糟糕的性能

Question

我的团队正在将数百个数据库对象从我们的 QA 服务器移动到我们的 UAT 服务器。所有新对象都位于 UAT 数据库中尚不存在的两个模式中。

我们在创建所有这些对象时做的第一件事是运行一些非常复杂的 View 来对我们的基表进行初始数据填充(是的， View 写得不好，将它们写成存储的效率会高得多procs，但这不是我的问题的重点)。

我们的大部分数据负载测试都是在所有对象都已经存在的数据库中完成的，并且性能很好。最长加载时间为十分钟。

但是，当我们将这些新模式/对象移动到不同的服务器并尝试加载数据时，相同的代码不会在 10 小时内完成。但是，如果我们尝试单独运行底层 View ，同时等待 View 的第一个练习完成，速度会非常快。

很明显这是优化器的问题(我们已经验证了服务器之间的代码完全相同:我们没有遗漏任何索引或统计信息)。如果我们取消长时间运行的查询并重新启动它们，那么性能与 QA 相匹配。

这是我们尝试过的:

• 重建所有索引。
• 使用全扫描更新所有统计信息。
• 我们已验证 SQL Server 不会创建超出索引自动创建的任何其他统计信息。
• DBCC FREESYSTEMCACHE('ALL')
• 新环境的规范比我们从中移植的环境更好:更多内核、更多内存、充足的空间。

虽然它仍然没有我们原来的环境那么快，但它还是有所不同。

我在这里错过了什么？除了清理优化器、索引和统计数据之外，还有什么可以插入性能？

我也不明白为什么优化器会为初始数据加载选择一个糟糕的计划，但随后，当该负载爬行时，如果我在另一个 cnn 上运行它，它会为相同的代码选择一个很好的计划。

SQL 版本为 SQL 2012，Svc Pack 3。

=========================

编辑:我知道没有人能够生成一段代码来解决我的问题。我很好奇是否有人知道我尚未探索过的区域。示例:

• 我用来刷新缓存的命令不完整。
• SQL Server 在内存中保留我不知道的统计信息(与我一起工作的 dba 提到了这一点，但没有提供链接，而且我在网上也没有看到任何信息)。
• 一个链接，解释优化器如何为 View 选择生成一个计划，然后在另一个 cnn 上同时为同一 View 选择提供完全不同的计划。
• 我需要查看但未提及的一些其他类型的指标。

Answer 1

我见过更快的硬件运行得更慢，因为它可能会遇到在较慢的硬件上不会突然出现的并发问题，尤其是在引入更多内核时。

检查您的 MAXDOP 设置。 CXPacket 等待可以指示并行性争用。 https://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/