3

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

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

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

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

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

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

查看性能

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

4

2 回答 2

3

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

现在，您只是测量响应时间，没有任何实际数据来说明花费的时间。没有提供单个实际数据点（收集的指标、其他人尝试的测试规范等），任何解释都可以冒险尝试正确的机会：客户端代码、锁定争用、文件增长、日志增长、索引统计信息、查询计划变化，人为错误，小精灵，月光，当然还有我最喜欢的：碎片。

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

于 2012-05-03T20:42:46.190 回答
1

您是否尝试过更新有关表的统计信息。

也许您的统计数据已过时，并且所使用的计划对于您的行数来说是错误的计划。

于 2012-05-04T00:25:42.580 回答