Как избежать «перестройки статистики» SQL Server при тестировании производительности?

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.Но мой вопрос состоит в том, как мы можем избежать этого во время длительного нагрузочного теста, кроме «переиндексации» для каждой таблицы перед тестированием.

И этот SQL будет использовать 16862 мс, потому что в моей таблице достаточно строк.И в моем тесте много вставок действий.

Answer 1

Это похоже на обновление статистики.

Произойдет ли обновление статистики в обычной производственной среде? Если да, то не должен ли нагрузочный тест отражать производственную среду и обновлять статистику?

Чтобы отключить параметр AUTO_UPDATE_STATISTICS, используйте sp_autostats для нужной таблицы (см. http://msdn.microsoft.com/en-us/library/ms188775.aspx).

Answer 2

Прежде чем что-либо изменить, я позволю ему работать как есть, с SQL Profiler, а затем получу Tuning Advisor для анализа результатов. Это может найти некоторые недостатки в дизайне таблицы. Также на это могут повлиять некоторые довольно невинные вещи: например, имея «слишком много индексов» или используя GUID в качестве PK для таблицы, в которой больше вставок, чем выбирает ...

Если все неэффективности устранены, а производительность все еще снижается, то да, вы можете отключить автостатистику и обновлять статистику в непиковое время. Но тогда вы должны сделать то же самое на производстве, как сказал человек.