Огляд плану виконання

Щоб мати можливість виконувати запити, SQL Server ядро ​​СУБД повинен проаналізувати інструкцію, щоб визначити ефективний спосіб доступу до необхідних даних і обробити його. Цей аналіз обробляється компонентом, який називається оптимізатором запитів. Вхідні дані оптимізатора запитів включають сам запит, схему бази даних (визначення таблиць та індексів) та статистику бази даних. Оптимізатор запитів створює один чи кілька планів виконання запитів, іноді називаються планами виконання запитів або планами виконання. Оптимізатор запитів вибирає план запиту за допомогою набору евристики для балансування часу компіляції та оптимальності плану пошуку хорошого плану запиту.

Щоб отримати додаткові відомості про плани обробки запитів та виконання запитів, див. у розділах , присвячених оптимізації інструкцій SELECT та кешування планів виконання та повторного використання посібника з архітектури обробки запитів.

Відомості про перегляд планів виконання в SQL Server Management Studio та Azure Data Studio див. у статті "Відображення та збереження планів виконання".

План виконання запиту – це визначення:

• Послідовності, де відбувається звернення до вихідним таблицям. Як правило, існує багато послідовностей, у яких сервер бази даних може звертатися до базових таблиць для побудови результуючого набору.Наприклад, якщо інструкція SELECT посилається на три таблиці, сервер бази даних спочатку може звернутися до TableA , використовувати дані з TableA для отримання відповідних рядків з TableB , а потім використовувати дані з TableB для вилучення даних з TableC . Інші послідовності, в яких сервер бази даних може звертатися до таблиць:
  TableC, TableB, TableA або
  TableB, TableA, TableC або
  TableB, TableC, TableA або
  TableC , , TableA TableB
• Методи, які використовуються для отримання даних з кожної таблиці. Існують різні методи для звернення до даних у кожній таблиці. Якщо потрібно лише кілька рядків з певними ключовими значеннями, сервер бази даних може використовувати індекс. Якщо необхідні всі рядки в таблиці, сервер бази даних може пропустити індекси і виконати перегляд таблиці. Якщо всі рядки таблиці необхідні, але є індекс, ключові стовпці якого знаходяться в елементі ORDER BY, виконання перевірки індексу замість сканування таблиці може зберегти окремий результуючий набір. Якщо таблиця невелика, сканування таблиць може бути найефективнішим методом майже всього доступу до таблиці.
• Методи, що використовуються для обчислень, а також фільтрації, статистичної обробки та сортування даних з кожної таблиці. У міру доступу до даних таблиць можна різними способами виконувати обчислення над даними (наприклад, обчислення скалярних значень), а також статистичну обробку та сортування даних, як визначено в тексті запиту (наприклад, при використанні пропозиції GROUP BY або ORDER BY ) та їх фільтрацію (наприклад, при використанні пропозиції WHERE або HAVING).

Пов'язаний контент

• Спостереження та налаштування продуктивності
• Засоби моніторингу продуктивності та налаштування
• Посібник з архітектури обробки запитів
• Динамічна статистика запитів
• Монітор активності
• Моніторинг продуктивності з використанням сховища запитів
• sys.dm_exec_query_statistics_xml
• sys.dm_exec_query_profiles
• DBCC TRACEON - прапори трасування (Transact-SQL)
• Довідник по оператору логічного та фізичного шоуплану
• Інфраструктура профілювання запитів
• Відображення та збереження планів виконання
• Порівняння та аналіз планів виконання
• Керівництва планів

SQL-Ex blog

5 речей, які вам потрібно знати для читання планів виконання SQL Server

Порядок плану виконання

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

Коли ви досягаєте оператора з'єднання або конкатенації, куди сходяться кілька гілок, ви можете перейти до крайнього правого оператора однієї з нижніх гілок і знову розпочати читання справа наліво. Загалом це може бути сформульовано як читання плану праворуч наліво та зверху донизу.

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

Стрілки

Стрілки показують напрямок потоку даних між операторами.

У плані виконання, який виводиться в SQL Server Management Studio, вони також становлять відносний розмір даних на цьому кроці.Брент Озар у своїй нещодавній статті докладно пояснив різницю між розмірами стрілок у передбачуваному та фактичному планах виконання. Коротко розмір стрілки представляє оцінку числа рядків на виході оператора-джерела в передбачуваних планів виконання та число рядків, які читає оператор-джерело в у фактичних планах виконання.

При аналізі планів ці відносні розміри стрілок підкажуть вам, де можна побачити в планах більше даних, ніж ви очікували.

Властивості операторів

При наведенні курсору на оператора (або стрілку) ви отримаєте додаткову інформацію про те, що цей оператор робить. Ця інформація включає не тільки опис оператора, але також показує кількість рядків, які SQL Server очікував прочитати на цьому кроці в порівнянні з фактично прочитаним значенням (при використанні фактичного плану виконання), які предикати застосовувалися, попереджувальні повідомлення та багато іншого.

Розгорнувши вікно властивостей (за замовчуванням F4) вибраного оператора, ви отримаєте ще більше інформації. Я зазвичай в цих властивостях звертаю увагу на використання пам'яті та процесора і те, які перетворення SQL Server робить при виконанні цієї частини мого запиту.

Вартість

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

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

Попередження

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

Звичайні винуватці цих попереджень - це оператори, що скидають дані в tempdb, неявні перетворення, які SQL Server повинен проводити для порівняння (що потенційно перешкоджає використанню індексу), і SQL Server повідомляє вам, що він перевищив/недооцінив кількість пам'яті, яку необхідно використовувати для виконання вашого запиту.

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

Рекомендації щодо індексів

Якщо SQL Server вважає, що продуктивність вашого запиту можна покращити за допомогою індексу, він повідомить про це, помістивши відповідний текст зеленого кольору вгорі плану виконання. Яка турбота!

Єдине ПЗ у тому, що ці рекомендації щодо індексів зазвичай не готові до використання. Не те щоб вони були погані, просто вони часто опускають додаткові стовпці, які слід включити, щоб зробити ваші запити більш ефективними, ніж ті, що будуть отримані на базі запропонованих рекомендацій.

Тим часом, ці рекомендації є гарною відправною точкою, і вам завжди слід звертати на них увагу з метою подальшого покращення запиту.

Зворотні посилання

Немає зворотних посилань

Коментарі

Показувати коментарі Як список | Деревоподібною структурою

Автор не дозволив коментувати цей запис