Во время исследования медленного запроса выяснилось, что план выполнения был исключительно неоптимальным (вложенный цикл, выполняющий 9 миллионов выполнений поиска, где предполагаемое количество выполнений было 1). Подтвердив, что некоторые соответствующие статистические данные, которые действительно устарели, я перестроил статистику, и проблема производительности была эффективно решена.
В этой базе данных включена статистика автоматического обновления (по умолчанию включена). Я понимаю, что существует порог для автоматических обновлений статистики на основе 20% + 500 модификаций строк (обновление / вставка / удаление). Это пороговое значение, по-видимому, было в значительной степени превышено по нескольким индексам, поэтому, по-видимому, существует либо (A) проблема с автоматическими обновлениями, либо (B) Существует больше возможностей для стратегии обновления, чем я смог найти в Интернете документация.
Я ценю, что запланированное задание может быть настроено для обновления статистики, и это, вероятно, тот подход, который мы используем, если не может быть найдено никакого другого решения, но это оставляет нас в замешательстве относительно того, почему такое большое количество изменений не вызовет автоматическое обновление некоторых статистических данных - понимание того, почему мы можем решить, какие статистические данные необходимо обновить с помощью запланированной задачи.
Некоторые дополнительные заметки:
1) Проблема была отмечена в базе данных, где данные создаются с помощью нагрузочного теста и, как таковое, большое количество данных добавляется за короткий промежуток времени, например, если автообновление происходит периодически (например, один раз в день в большинство), то это может объяснить некоторые наблюдаемое поведение. Кроме того, наши нагрузочные тесты, как правило, сильно нагружают базу данных, поэтому мне интересно, не откладывает ли SQL обновление статистики, пока есть большая нагрузка (и впоследствии не обновляет статистику по какой-то причине).
2) При попытке воссоздать эту проблему с помощью тестового сценария, содержащего последовательные операторы INSERT, SELECT и DELETE, проблема не возникла. Мне интересно, различие здесь в том, что каждый из этих операторов влияет на множество строк в каждом операторе SQL, тогда как наш сценарий нагрузочного теста будет стремиться вставлять строки по отдельности.
3) БД, о которой идет речь, настроена на «простую» модель восстановления.
Некоторые соответствующие ссылки:
- Контрольный список для анализа медленных запросов
- Использование статистики для улучшения производительности запросов
Я также поднял эту проблему через Microsoft Connect:
ОБНОВЛЕНИЕ 2011-06-30:
При дальнейшем изучении я считаю, что статистика, которая устарела за пределами пороговых уровней (например, 500 строк + 20%), является статистикой, которая не используется проблемным запросом, поэтому, вероятно, она будет обновлена при выполнении запроса это требует их. Для статистики , которые являются используемой в запросе, они регулярно обновляются. Остается проблема в том, что эти статистические данные сильно вводят в заблуждение оптимизатора плана запросов только после относительно небольшого количества вставок (например, в результате чего вышеупомянутые 9 миллионов или около того ищут, где оценочное число было 1).
Я догадываюсь, что проблема связана с неправильным выбором первичного ключа, ключ является уникальным идентификатором, созданным с помощью NEWID (), и поэтому очень быстро создает сильно фрагментированный индекс - особенно в качестве коэффициента заполнения по умолчанию в SQL. Сервер на 100%. Я предполагаю, что это как-то приводит к вводящей в заблуждение статистике после относительно небольшого количества вставок строк - меньше порогового значения для пересчета статистики. Возможно, это все не проблема, поскольку я сгенерировал много данных без перестройки индексов, поэтому плохая статистика может быть следствием очень высокой фрагментации индекса. Я думаю, что мне нужно добавить циклы обслуживания SQL Server в свой нагрузочный тест, чтобы получить лучшее представление о производительности в реальной системе в течение длительных периодов времени.
ОБНОВЛЕНИЕ 2012-01-10:
Еще один фактор для рассмотрения. В SQL Server 2005 были добавлены два флага трассировки (и, похоже, они все еще присутствуют в 2008 году) для устранения конкретных недостатков, связанных с появлением устаревшей и / или вводящей в заблуждение статистики. Указанные флаги:
DBCC TRACEON(2389)
DBCC TRACEON(2390)
MSDN: Ian Jose WebLog: восходящие ключи и автоматическая быстрая коррекция статистики по восходящим столбцам, Фабиано Аморим
Конечно, вы должны быть очень осторожны при принятии решения о включении этих флагов, поскольку они могут иметь вредные последствия.