Понимание статистики, планов выполнения и «восходящей ключевой проблемы»


11

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

Правильно ли я сказал, что статистика используется только при создании плана выполнения хранимой процедуры и не используется в реальном контексте выполнения? Другими словами, если это так, то после того, как план создан (и при условии, что он правильно используется), насколько важна актуальная статистика?

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

У нас есть возрастающий столбец даты / времени в одной из наших самых больших таблиц, которые мы регулярно запрашиваем с помощью определенной хранимой процедуры.

Как вы предотвращаете устаревание планов выполнения, если в день добавляется по сто тысяч строк?

Если мы часто обновляем статистику для решения этой проблемы, имеет ли смысл использовать подсказку OPTION (RECOMPILE) для запроса этой хранимой процедуры?

Любые советы или рекомендации будут оценены.

Обновление : я использую SQL Server 2012 (SP1).

Ответы:


5

Правильно ли я сказал, что статистика используется только при создании плана выполнения хранимой процедуры и не используется в реальном контексте выполнения?

Нет, происходит следующее: план выполнения хранимой процедуры кэшируется. Если предположить, что памяти достаточно для продолжения хранения плана, она не изменится, если не произойдет одно из следующих событий (из раздела Кэширование и повторное использование плана выполнения в документации по SQL Server, выделение выделено):

  • Изменения, внесенные в таблицу или представление, на которые ссылается запрос (ALTER TABLE и ALTER VIEW).
  • Изменения, внесенные в одну процедуру, которая удаляла бы все планы для этой процедуры из кэша (ALTER PROCEDURE).
  • Изменения любых индексов, используемых планом выполнения.
  • Обновления статистики, используемые планом выполнения, генерируемые либо явно из инструкции, такой как UPDATE STATISTICS, либо генерируемые автоматически.
  • Удаление индекса, используемого планом выполнения.
  • Явный вызов sp_recompile.
  • Большое количество изменений ключей (генерируемых операторами INSERT или DELETE от других пользователей, которые изменяют таблицу, на которую ссылается запрос).
  • Для таблиц с триггерами, если количество строк во вставленных или удаленных таблицах значительно возрастает.
  • Выполнение хранимой процедуры с использованием параметра WITH RECOMPILE.

Поэтому, если статистика обновляется, кэшированный план автоматически учитывает новую статистику и перекомпилируется.

Как вы предотвращаете устаревание планов выполнения, если в день добавляется по сто тысяч строк?

Один из них - если в таблице много обновлений, как указано выше. Несколько сотен тысяч измененных строк могут удовлетворить это условие. Но если вы хотите быть уверены или имеете более детальный контроль: обновите свою статистику. Вы можете разрешить SQL Server автоматически создавать и управлять статистикой или вручную делать это самостоятельно. Вы можете найти дополнительную информацию о любом из этих методов в разделах «Автоматическое обновление SQL Server» и «Параметры автоматического создания статистики» . Когда / если вы выполняете еженедельную перестройку индексов, это также приведет к обновлению планов. Проведите некоторое тестирование, чтобы увидеть, что для вас наиболее выгодно, поскольку слишком частое обновление статистики может не дать никаких реальных результатов производительности.

Если мы часто обновляем статистику для решения этой проблемы, имеет ли смысл использовать подсказку OPTION (RECOMPILE) для запроса этой хранимой процедуры?

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


RECOMPILEне приведет к обновлению статистики в любом случае.
Мартин Смит

@MartinSmith Правильно! Я буду редактировать, чтобы сделать это более ясным.
LowlyDBA

@LowlyDBA Не могли бы вы обратиться к следующей теме? dba.stackexchange.com/questions/207475/…
lukaszwinski

6

Правильно ли я сказал, что статистика используется только при создании плана выполнения

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

У нас есть возрастающий столбец даты / времени в одной из наших самых больших таблиц, которые мы регулярно запрашиваем

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

  • Трассировка флагов 2389 и 2390 . Это требует наличия индекса с проблемным столбцом в качестве ведущего ключа. Он не работает с многораздельными таблицами и эффективен только в SQL Server 2014, если используется исходная оценка мощности. Флаг трассировки 4139 также может потребоваться, если объект статистики является марочным стационарным.

  • Обновление до SQL Server 2014. Новый оценщик количества элементов содержит логику для оценки за пределами гистограммы с использованием информации о средней плотности. Это может быть менее точным, чем флаги трассировки 2389/2390 при некоторых важных обстоятельствах.

  • Включите более частые автоматические обновления статистики для больших таблиц с флагом трассировки 2371 . С этим флагом трассировки вместо обновления после 20% + 500 изменений требуются только SQRT(1000 * Table rows)модификации . Это не такое полное решение, как упомянутое ранее, поскольку обновления могут запускаться недостаточно часто.

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

  • Отключение сниффинга параметров с помощью флага трассировки 4136
  • Использование OPTIMIZE FOR (@parameter = value)для составления плана для известного представительного значения
  • Использование OPTIMIZE FOR (@parameter UNKNOWN)для оптимизации с использованием среднего распределения
  • Использование OPTIMIZE FOR UNKNOWN(аналогично 4136, но для каждого запроса)
  • Используя OPTION (RECOMPILE)для компиляции каждый раз, вынюхивая определенное значение. Если подавляющее большинство значений времени выполнения находится в гистограмме, это может быть эффективным.

Для получения дополнительной информации о параметрах сниффинг, встраивание и параметры перекомпиляции см. Мою статью на SQLperformance.com.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.