Question

我现在正在做一些SQL调优，并在测试期间找到一个奇怪的SQL：

SELECT StatMan([SC0],[SC1], [SB0000]) 
FROM (SELECT TOP 100 PERCENT [SC0],[SC1], step_direction([SC0]) over (order by NULL) AS [SB0000]  
      FROM (SELECT [tableA] AS [SC0],[tableB] AS [SC1] 
            FROM [dbo].[url] WITH (READUNCOMMITTED,SAMPLE 3.408654e+000 PERCENT) 
           ) AS _MS_UPDSTATS_TBL_HELPER 
     ORDER BY [SC0],[SC1], [SB0000] 
    ) AS _MS_UPDSTATS_TBL  
OPTION (MAXDOP 1)

根据SQL Server，看起来这是在做一些“reindex”或“重建”某些db索引。但我的问题是，在测试之前，除了每个表的“reindex”之外，我们如何在长负载测试期间避免这种情况。

由于我的表包含足够的行，这个SQL将消耗16862ms。我的测试中有很多插入动作。

Answer 1

这似乎来自更新统计数据。

更新统计信息是否会在正常的生产环境中发生？如果是这样，不应该进行负载测试，以反映生产环境，还要更新统计信息吗？

要关闭AUTO_UPDATE_STATISTICS选项，请在所需的表上使用sp_autostats（请参阅http://msdn.microsoft.com/en-us/library/ms188775.aspx）。

Answer 2

在更改任何内容之前，我会让它按原样运行，使用SQL事件探查器，然后让Tuning Advisor分析结果。它可以在表格设计中发现一些效率低下的问题。还有一些非常无辜的东西会影响它：例如拥有“太多索引”或使用GUID作为具有更多插入而不是选择的表的PK ...

如果所有低效率都得到解决，并且您的性能仍然受到影响，那么您可以关闭自动统计信息并在非高峰时段更新统计信息。但是你必须在生产中做同样的事情，就像以前的人所说的那样。

如何在进行性能测试时避免SQL Server“重建统计信息”？

2 个答案: