У попередній лекції ви навчилися отримувати зведену інформацію про дані, що зберігаються у вашій базі даних. SQL Server може повертати результати, в тому числі, зведену інформацію, швидко і ефективно, якщо дані правильно зберігаються в базі даних. У цій лекції пояснюються різні способи зберігання і вилучення даних в SQL Server. а також розповідається про те, які чинники слід враховувати при розробці бази даних. щоб домогтися найбільш ефективної продуктивності від SQL Server.
плани запитів
Коли сервер SQL Server виконує запит. спочатку потрібно визначити найкращий спосіб виконання. Для цього потрібно розрахувати, як і в якому порядку звертатися до даних і з'єднувати їх, як і коли виконувати обчислення та агрегації і т. Д. За це відповідає підсистема, яка називається Query Optimizer (оптимізатор запиту). Оптимізатор запиту використовує статистичні дані про розподіл даних, метадані. які стосуються об'єктах в базі даних, інформацію індексу і інші чинники для обчислення декількох можливих планів виконання запиту. Для кожного з цих планів оптимізатор запиту передбачає його вартість на основі статистики за цими даними і вибирає план з мінімальними витратами ресурсів на виконання. Звичайно, SQL Server не вирахував всіх можливих планів для кожного запиту, оскільки для деяких запитів самі ці обчислення можуть забрати більше часу, ніж виконання найменш ефективного з усіх планів. Отже, SQL Server використовує складні алгоритми, щоб знайти план виконання з розумною вартістю, близькою до мінімально можливої. Після того, як план виконання згенерований, він зберігається в буферному кеші (на що SQL Server виділяє більшу частину своєї віртуальної пам'яті). Потім план виконується тим способом, який оптимізатор запиту повідомляє ядру бази даних (компоненту database engine).
Чи зможе Query Optimizer (оптимізатор запитів) згенерувати ефективний план для конкретного запиту, залежить від наступних факторів:
- Індекси інфляції. Подібно змісту в книзі, індекс бази даних дозволяє швидко знайти певні рядки в таблиці. У таблиці може бути не один індекс. Завдяки наявності в таблиці індексів, оптимізатор запитів SQL Server може оптимізувати доступ до даних, вибравши для використання відповідний індекс. Якщо індекси відсутні, у оптимізатора запитів залишається тільки один варіант, який полягає в скануванні всіх даних, наявних в таблиці, в пошуку потрібних рядків. Далі в цій лекції наводиться інформація про те, як працюють індекси і як їх розробляти і проектувати.
- Статистика розподілу даних: SQL Server зберігає статистику про розподіл даних. Якщо ця статистика відсутня або застаріла, оптимізатор запитів не зможе обчислити ефективний план виконання запиту. У більшості випадків, статистичні дані генеруються і оновлюються автоматично. Далі в цій лекції розповідається про те, як генеруються статистичні дані і як можна управляти статистикою.
Як бачите, генерування плану виконання запитів - це функція. важлива для продуктивності SQL Server. оскільки ефективність плану виконання запиту визначає, чи буде час його виконання вимірюватися в мілісекундах, секундах або навіть хвилинах. Плани виконання запитів, які показали низьку швидкість виконання, можна проаналізувати, щоб визначити, чи є індекс. застаріли дані статистики або просто SQL Server вибрав не найефективніший план (таке трапляється не дуже часто).
Знайомимося з планами виконання запитів
При генеруванні передбачуваного плану запиту запит насправді не виконується. Він тільки оптимізується оптимізатором запиту. Ця особливість оптимізатора запитів є перевагою, коли доводиться мати справу з запитами, які мають тривалі робочі цикли. адже для того, щоб побачити план виконання запиту, немає необхідності виконувати сам запит. Графічне представлення плану виконання запиту читається справа наліво і зверху вниз. Кожен значок в плані являє один оператор, а дані, що змінюються між цими операторами, позначені стрілками. Товщина стрілок відповідає обсягу даних, які передаються між операторами. Ми не будемо заглиблюватися в подробиці і пояснювати значення кожного оператора; розповімо тільки про тих з них, які показані в даному плані виконання запиту.