Зачем устанавливать автоматическое обновление статистики на False?

Я только что унаследовал около 20 экземпляров SQL Server, как часть более широкого проекта по приобретению. Я нахожусь в процессе оценки производительности, и мне не нравится, как планы обслуживания были выполнены.

Я вижу ежедневные перестройки общего индекса (я могу справиться с этим), а также ежедневное ручное обновление статистики.

Около половины баз данных было установлено на Автоматическое обновление статистики = Ложь по причинам, которые не ясны, за исключением того, что мне сказали, что это уменьшает «Проблемы с производительностью» ...

Я всегда думал и работал над тем, чтобы установить для этого параметра значение True, и чувствовал, что обновление вручную не требуется, если для этого параметра установлено значение True. Я ошибся?

Может ли кто-нибудь объяснить, что было бы полезно, если бы этот параметр был установлен как False, но вместо этого выполнял ежедневное обновление вручную?

Я должен отметить, что некоторые базы данных имеют высокую транзакционность (миллионы вставок, удалений, обновлений в день). Другие базы данных имеют низкую скорость транзакций, а некоторые только для чтения. Там нет рифмы или причины, по которой для параметра автоматического обновления установлено значение False. Похоже, это лотерея.

Вы правы, я также считаю, что в большинстве случаев Auto Update statisticsследует установить значение true, мы должны позволить SQL Server решать, когда обновлять статистику, и верить, что он хорошо работает. Если для этого параметра установлено значение true, убедитесь, что статистика обновляется о распределении данных в поле, что в конечном итоге поможет оптимизатору подготовить лучший план. Здесь важно отметить, что статистика автоматического обновления срабатывает, когда в таблице изменяется 20% данных. Таким образом, вы не должны чувствовать, что в таблице с 100K строк, если обновлено 10 строк, обновление состояния будет запущено.

Более глубокий анализ сделан Полом Рэндалом в блоге « Понимание того, когда статистика будет автоматически обновляться» . Я не видел никаких недостатков, если эта опция установлена ​​в true. Да, вы можете увидеть некоторые операции ввода-вывода, если для этого параметра установлено значение true.

Важный вывод, который можно сделать из блога

Даже если статистика устарела в результате изменения, она не будет автоматически обновляться после ее завершения. Статистика будет автоматически обновляться при следующем использовании плана запроса.

В тех случаях, когда вы просто читаете только базы данных или базы данных, в которых вы просто выбираете операцию, а операция DML отсутствует, в этом случае вы можете оставить опцию ложной, но опять-таки никакого вреда не будет, если вы сохраните ее. В основном мы видим базу данных с определенной активностью.

Это слишком долго для комментария, поэтому я приведу еще один случай, когда можно отключить автоматическое обновление статистики. Я работал с базами данных, поддерживающими большие объемы рабочих нагрузок OLTP и строгий SLA производительности запросов в миллисекундах. Почти все запросы были тривиальными, с большим вниманием к деталям настройки запросов и индексов, а некоторые таблицы были довольно большими. В этой ситуации не было особой ценности в обновлении статистики в периоды пиковой нагрузки, и автоматическое обновление статистики нарушало бы SLA. Следовательно, обслуживание выполнялось в непиковые периоды с помощью запланированной работы.

Другой вариант - включить оба параметра AUTO_UPDATE_STATISTICSи AUTO_UPDATE_STATISTICS_ASYNCпараметры базы данных. Это позволит запросам выполнять планы выполнения, основанные на устаревшей статистике, а не накладывать накладные расходы на синхронное обновление статистики. Это особенно подходит для рабочей нагрузки OLTP, если размер сервера соответствует рабочей нагрузке запроса плюс обновление фоновой статистики.

В целом, я бы сказал, что иметь статистику автоматического обновления полезно. Но, как и для любой настройки, есть причины, по которым вы можете включить или выключить ее.

Одна из них заключается в том, что некоторые таблицы имеют большой отток, и, возможно, запросы не очень чувствительны к точной статистике. Подумайте об ETL или других массовых сценариях, в которых вы меняете много данных, но либо не читаете их оттуда, либо не читаете много. Нет особого смысла в том, чтобы запускать автоматические обновления статистики и вызывать кучу операций ввода-вывода для обеспечения более точной статистики, которая никогда не будет использоваться.

У вас также могут быть сценарии, в которых вы обновляете данные несколько раз в течение дня, но не обязательно хотите обновлять статистику после каждого обновления. (Скажем, данные запрашиваются только в определенные часы дня - нет необходимости многократно обновлять статистику, если данные все равно не будут запрашиваться за все время.)

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