Главная » Microsoft SQL Server, Базы данных » Повторное использование планов выполнения запросов

0

Как было продемонстрировано в statistics time, время разбора и компиляции запроса может быть достаточно большим. Сохранение планов выполнения запросов может оказаться критичным для поддержания высокой производительности базы. Когда запрос определен, во время его первого выполнения SQL Server старается сохранить его план в процедурном кэше.

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

Оптимизатор запросов выбирает наилучший индекс и корректный метод объединения на основании прогноза количества строк, возвращаемого каждой операцией. Этот прогноз зависит от двух факторов: параметров запроса и статистики индексов.

Чтобы проиллюстрировать этот тезис, предположим, что большинство клиентов вашей компании расположены локально — скажем, в Москве. Естественно, у вас есть заказчики и из других регионов страны, и даже несколько зарубежных. Рассматриваемый запрос ищет всех заказчиков из Москвы. SQL Server создает отличный план выполнения запроса, использующий сканирование кластеризованного индекса, так как из таблицы отбирается большая часть строк. После этого план сохраняется в памяти.

Теперь предположим, что через пару минут компания сливается с компанией в Санкт- Петербурге, которая в десять раз больше по размерам. Данные при этом также объединяются, и следующий запрос ищет заказчиков из Урюпинска. Исходный план запроса был основан на предположении о том, что будет отбираться большая часть строк таблицы. Теперь этот план оказался непригодным, поскольку в Урюпинске насчитывается всего несколько клиентов.

К счастью, SQL Server обладает интеллектуальной способностью определять, какой план следует перекомпилировать, основываясь на изменении данных и параметров. SQL Server хранит статистику распределения данных по таблицам, так что всегда можно сказать, как строки распределены между Москвой, Петербургом и Урюпинском.

Формирование статистики обычно установлено в автоматический режим, и SQL Server обновляет ее, когда в таблицу вставляется объем данных, способный ее поколебать. Однако временами пользователям из соображений быстродействия требуется отключать автоматический режим, например, когда в таблицу вставляется или удаляется из нее миллион строк.

С помощью команды DBCC вы можете управлять статистикой вручную (см.

Новинка главу 37).

2005

Чтобы запрос был сохранен в памяти, он должен иметь параметры — не только константы, но и использующие синтаксис параметр^ значение. К счастью, SQL Server автоматически параметризирует запрос, заменяя литералы и константы запроса параметрами, что позволяет сохранить запрос.

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

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

DBCC FREEPROCCACHE

Для проверки процедурного кэша используется таблица syscacheob j ects:

SELECT cast(C.sqi as Char(35)) as StoredProcedure, cacheobjtype, usecounts as Count FROM Master.dbo.syscacheobjects С JOIN Master.dbo.sysdatabases D ON C.dbid = C.dbid WHERE D.Name = DB_Name()

AND ObjType = ‘Adhoc’

ORDER BY StoredProcedure

Результат (усеченный):

cacheobjtype             Count                               StoredProcedure

Compiled Plan           1                                       INSERT [Lumigent_Profiler]([Pre

Executable Plan 1                                              SELECT LastName + 1 ‘ + FirstNa

Compiled Plan           1                                       SELECT LastName + ‘ ’ + FirstNa

Compiled Plan           1                                       UPDATE msdb.dbo.sysjobschedules

Производительность зависит от комбинации запроса, индексов и данных. Сохраненный план запроса будет полезным только до тех пор, пока статистика данных, индексы и параметры остаются единообразными. Когда структура таблицы или индексов изменяется, или обновляется статистика данных, или обновляется значительный объем данных, SQL Server помечает запрос как бесполезный и создает новый план во время следующего выполнения этого запроса.

Для эффективного управления памятью планы запросов также имеют свой срок хранения в памяти; при этом наиболее сложные запросы удаляются дольше всего.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии