Целесообразность использования STATISTICS_NORECOMPUTE

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

Когда я сравнил тестовую и модельную среду, то заметил, что большинство индексов в модельной среде STATISTICS_NORECOMPUTEнастроены, ONа тестируемые - нет. Во всех средах существует ночная работа, которая обновляет статистику всех баз данных.

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

РЕДАКТИРОВАТЬ: Я нашел один из блогов Кимберли Трипп на эту тему здесь, который, кажется, предлагает, STATISTICS_NORECOMPUTEчтобы в лучшем случае использовался экономно. Но я все еще беспокоюсь о том, чтобы отключить его во всем мире. Кто-нибудь пробовал это и что они испытали?

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

В любом случае, общая рекомендация оставлять статистику автоматического обновления включенной ( STATISTICS_NORECOMPUTE = OFFпо умолчанию) - из соображений безопасности, потому что, если она отключена и ничто не обновляет статистику вручную, результатом могут быть действительно ужасные планы выполнения, которые никогда не изменятся. после того, как они впервые созданы (и не становятся недействительными по другим причинам позже).

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

Думая об этом больше, я скажу, что нынешняя стратегия имеет смысл. Это лучше, чем оставить статистику автообновления для всего? Похоже, что кто-то так подумал, до такой степени, что он стоил простого компромисса с наличием связанной работы агента SQL.

Если идея состояла в том, чтобы иметь свежую статистику, доступную без блокировки запросов (как этот ), вы могли бы включить автоматическое обновление для всего, а затем также включить AUTO_UPDATE_STATISTICS_ASYNC. Затем, вероятно, измените график работы так, чтобы он выполнялся один раз в неделю, а не ежедневно, поскольку вы все еще хотите, чтобы статистика WITH FULLSCANпериодически обновлялась .

Я мог бы просто оставить это, поскольку у вас, вероятно, есть более крупная рыба, которую нужно жарить, если сами индексы различаются в разных средах, и перестройка статистики не слишком болезненна. То, что там сейчас, имеет смысл; вам просто нужно сделать вещи согласованными в разных средах. Это, вероятно, немного лучше, чем простые настройки, которые я предложил, за счет большего объема работы. Но узнайте, что находится в производстве, стремитесь использовать это и переходите к более важным вещам; вернитесь к этому, когда вам понадобится более точно настроить производительность - лучшая статистика в мире не сохранит запрос, в котором отсутствует критический индекс.