SQL Server视图的性能测试结果出人意料，为什么？

Question

最近，我们对一些SQL Server视图进行了一些更改，这些更改可能会对性能产生负面影响。我们决定对这些视图运行一些性能测试，以查看我们对它们产生的影响。结果令人惊讶。

下面的图表显示了我们运行的性能测试结果。以下是图表的含义：

- 蓝线表示在进行任何更改之前的视图。 - 红线表示更改后的视图。 - x轴表示循环中的迭代次数。

- 每次迭代，会插入一千条新记录（视图将返回这些记录）。 - 每次迭代，我们从正在测试的视图中选择几个并平均结果。

- y轴表示视图返回结果所需的时间。 - 进行性能测试的select语句带有where子句，每次只返回100条记录（测试期间每个名称都插入了100条记录）。

结果表明，我们确实会遇到性能问题，但让我们困惑的是，一旦数据库中的记录达到约40,000条，性能就会大幅提高。我们在多台不同的服务器上运行了这个测试，并且每次得到类似的结果。

我想知道是否有人可以解释为什么会发生这种情况。为什么我们突破了40,000条记录水平后会获得巨大的性能提升？有人见过类似的情况吗？我尝试搜索一些原因，但没有找到什么有用的信息。

我们尝试调整视图、调整索引、重建和重新组织索引、分析执行计划以及其他各种方法，但到目前为止，我们还没有找到任何可能导致这种情况的原因。

如下是图表：

任何帮助或见解都将不胜感激。谢谢。

- Jacob Adams

---

粗略的表结构、索引和视图查询是什么？根据没有信息的最佳猜测，您正在对表进行索引扫描，但实际上不应该这样做，数据库最终会意识到并执行全面扫描。 - Ben

视图非常复杂，索引和表结构也是如此。我只是在寻找诊断此问题的想法。我会更深入地研究你提到的索引扫描与表扫描。谢谢。 - Jacob Adams

请发布实际执行计划的“之前”和“之后”的屏幕截图。在“输入大小”下运行查询，以便您对性能差异感到惊讶。问题很可能是基数估计错误。 - usr

发布执行计划会更有帮助。 - James Johnson

由于查询计划的庞大，将其张贴在此处是不切实际的。您的几个回复已经帮助我找到了正确的方向。正如@usr所指出的那样，我相信这确实与基数估计错误有关。 - Jacob Adams

你是怎么进行这个测试的？我想要能够做类似的事情来进行视图更改。 - whytheq

Answer 1

你应该像处理其他性能问题一样，使用可靠的方法和测量。等待和队列将是识别瓶颈的无价之宝。一旦你确定并测量了相关指标，就可以得出答案。

现在，你只是测量了响应时间，没有实际数据来说明时间如何被消耗。没有一个实际的数据点被呈现（收集的指标、供他人尝试的测试规范等），任何解释都可能同样正确：客户端代码、锁争用、文件增长、日志增长、索引统计信息、查询计划更改、人为错误、小精灵、月光等等，当然，我的最爱是碎片化。

因此，要么进行适当的分析和调查，并收集相关指标，要么发布精确的测试（重现脚本、方法），以便我们自己进行测量。

- Remus Rusanu

Answer 2

你尝试过更新涉及的表的统计信息吗？

也许你的统计信息已经过期，使用的计划是针对你的行数错误的计划。

- Steve Stedman

---

+1 我相信SQL Server可能会在修改X％的行后自动更新统计信息，因此每1000行不一定会更新统计信息，它们可能会过时。另外一个随机猜测：当并行成本小于并行查询的预估性能惩罚时，40K记录是一个合适的阈值。 - ta.speot.is