Повторне використання планів виконання запитів

Як було продемонстровано в statistics time, час розбору і компіляції запиту може бути досить великим Збереження планів виконання запитів може виявитися критичним для підтримки високої продуктивності бази Коли запит визначений, під час його першого виконання SQL Server намагається зберегти його план в процедурному кеші

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

Оптимізатор запитів вибирає найкращий індекс і коректний метод обєднання на підставі прогнозу кількості рядків, що повертається кожною операцією Цей прогноз залежить від двох факторів: параметрів запиту і статистики індексів

Щоб проілюструвати цю тезу, припустимо, що більшість клієнтів вашої компанії розташовані локально – скажімо, в Москві Природно, у вас є замовники і з інших регіонів країни, і навіть кілька закордонних Розглянутий запит шукає всіх замовників з Москви SQL Server створює відмінний план виконання запиту, що використовує сканування кластеризованого індексу, так як з таблиці відбирається велика частина рядків Після цього план зберігається в памяті

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

На щастя, SQL Server володіє інтелектуальною здатністю визначати, який план слід перекомпілювати, грунтуючись на зміну даних і параметрів SQL Server зберігає статистику розподілу даних за таблицями, так що завжди можна сказати, як рядки розподілені між Москвою, Петербургом і урюпинск

Формування статистики зазвичай встановлено в автоматичний режим, і SQL Server оновлює її, коли в таблицю вставляється обсяг даних, здатний її похитнути Проте часом користувачам з міркувань швидкодії потрібно відключати автоматичний режим, наприклад, коли в таблицю вставляється або віддаляється з неї мільйон рядків

За допомогою команди DBCC ви можете керувати статистикою вручну (див

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

2005

Щоб запит був збережений в памяті, він повинен мати параметри – не тільки константи, але і використовують синтаксис параметр ^ значення На щастя, SQL Server автоматично параметрізірует запит, замінюючи літерали і константи запиту параметрами, що дозволяє зберегти запит

Більш суворе умова вимагає, щоб всі посилання на таблиці було правильно формалізовані (тобто мали принаймні двухкомпонентную форму схема Таблиця), і тоді план запиту може бути збережений

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

DBCC FREEPROCCACHE

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

SELECT cast (Csqi as Char (35)) as StoredProcedure, cacheobjtype, usecounts as Count FROM Masterdbosyscacheobjects З JOIN Masterdbosysdatabases D ON Cdbid = Cdbid WHERE DName = 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 msdbdbosysjobschedules

Продуктивність залежить від комбінації запиту, індексів і даних Збережений план запиту буде корисним тільки доти, поки статистика даних, індекси і параметри залишаються однаковими Коли структура таблиці або індексів змінюється, або оновлюється статистика даних, або оновлюється значний обсяг даних, SQL Server позначає запит як даремний і створює новий план під час наступного виконання цього запиту

Для ефективного управління памяттю плани запитів також мають свій термін зберігання в памяті при цьому найбільш складні запити видаляються найдовше

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*