sql - SQL Server View 的性能测试产生了令人惊讶的结果。为什么？

Question

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

下图显示了我们运行的性能测试的结果。这是图表所代表的内容:

• 蓝线是未进行任何更改之前的 View 。
• 红线显示了更改后的 View 。
• x 轴表示循环中的迭代。
  • 每次迭代，插入一千条新记录( View 将返回)。
  • 每次迭代，我们都会从我们正在测试的 View 中进行多次选择，并对结果进行平均。
• y轴代 TableView 返回结果所花费的时间
• 经过性能测试的 select 语句有一个 where 子句，每次只返回 100 条记录。 (测试时每个名字插入100条记录)。

结果告诉我们，我们确实受到了性能影响，但让我们感到困惑的是，一旦我们在数据库中达到大约 40,000 条记录，性能就会大幅提高。我们在几个不同的服务器上运行了这个测试，每次都得到相似的结果。

我想知道是否有人可以深入了解为什么会发生这种情况。当我们突破 40,000 记录水平时，为什么我们会获得巨大的性能提升？有没有人见过这样的事情？我曾尝试为此寻找一些原因，但一无所获。

我们尝试过调整 View 、扰乱索引、重建和重组索引、分析执行计划以及各种其他操作，但到目前为止我们还没有发现任何会导致这种情况的原因。

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

Answer 1

您应该像处理任何其他性能调查一样处理此问题:使用合理的方法和衡量标准。 Waits and Queues作为一种识别瓶颈的方法，它将再次成为无价之宝。一旦您确定并衡量了相关指标，就可以给出正在发生的事情的答案。

现在您只是测量响应时间，没有关于时间花费情况的任何实际数据。没有提供单个实际数据点(收集的指标、供其他人尝试的测试规范等)，任何的解释都可能是正确的:客户端代码、锁定争用、文件增长、日志增长、索引统计、查询计划更改、人为错误、gremlins、月光，当然还有我最喜欢的:fragmentation .

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