Архітектура обробки sql запитів в microsoft sql server

32

Вітаю вас на сайті info-comp.ru! сьогодні ми з вами розберемо внутрішню архітектуру обробки sql запитів в microsoft sql server.

Справа в тому, що між тим моментом, коли ми натиснули кнопку “виконати”, тобто послали sql запит, і моментом, коли ми побачили запитувані дані, всередині sql server виконується величезна, багатоетапна робота, про яку корисно знати всім розробникам і адміністраторам microsoft sql server.

Іншими словами, сьогодні ми поговоримо про те, що саме відбувається, так би мовити, за «лаштунками» в той момент, коли ми посилаємо запит на sql server.

Введення в архітектуру обробки запитів в sql server

Багато починаючі розробники думають, що, коли ми запускаємо sql запит на виконання, microsoft sql server просто парсит текст запиту і відразу повертає нам дані. Однак це не так.

Sql server перед тим, як повернути нам результат, тобто. Дані, виконує досить багато складних різних операцій, іншими словами, дані нам повертаються тільки після роботи складного внутрішнього механізму, про який ми зараз і поговоримо, тобто про те, що насправді відбувається з моменту, коли ми натиснули кнопку «виконати» і послали sql запит, до того, коли ми побачили запитувані дані.

Отже, всередині sql server працює складний механізм, роботу якого забезпечують кілька спеціально створених так званих «движків», кожен з яких відповідає за певну ділянку роботи.

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

Relational engine включає кілька етапів обробки sql запиту. Можна виділити 3 основних, глобальних етапи:

  • query parsing
  • query optimization
  • query execution

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

Давайте трохи докладніше поговоримо про кожен етап обробки sql запиту компонентом relational engine, таким чином, ви будете розуміти, які процеси запускаються, коли ми виконуємо sql запит в microsoft sql server.

Query parsing

Parsing

На даному етапі виконуються наступні дії:

  • читання і розбір тексту запиту
  • генерування хешу по тексту запиту
  • перевірка кешу планів, тобто пошук відповідного плану в кеші. Іншими словами, якщо для даного тексту запиту раніше вже був сформований план виконання, то необов’язково виконувати всі подальші дії, так як можна взяти план з кешу
  • синтаксичний аналіз
  • побудова дерева логічних операторів

Algebrizer

На даному етапі відбувається так званий binding – це перевірка на існування об’єктів бази даних, стовпців в таблицях, які вказані у запиті, а також зіставлення кожного об’єкта дерева з реальним об’єктом системного каталогу.

Результатом етапу query parsing є query tree (дерево запиту, тобто дерево логічних кроків, необхідних для перетворення вихідних даних у формат, необхідний результуючому набору).

план виконання запиту 8>–>- це набір конкретних дій, виконання яких приведе sql запит до підсумкового результату.

Іншими словами, план виконання запиту – це те, як саме буде виконуватися призначений для користувача запит, тобто. Як саме буде здійснюватися доступ до вихідних даних, в якому порядку, які конкретні методи будуть використовуватися для вилучення даних з кожної таблиці, які конкретні методи будуть використані для обчислень, фільтрації, статистичної обробки та сортування даних.

А вся справа в тому, що sql server може виконати запит і отримати одні і ті ж дані різними способами, тобто набір фізичних операцій в різних умовах буде відрізнятися.

Таким чином, робота оптимізатора полягає якраз у створенні оптимального плану виконання запиту, при якому результат повертається швидше за все і задіяно найменше ресурсів.

Даний етап, тобто. Процес оптимізації запиту, включає кілька фаз, зокрема:

  • simplification
  • trivial plan optimization
  • full optimization
    • search 0
    • search 1
    • search 2

Simplification

На даному етапі відбувається спрощення дерева запиту, наприклад:

  • видалення непотрібних сполук
  • розгортання підзапитів у з’єднання (якщо це можливо)
  • умови фільтрації можуть бути переміщені в початок дерева запиту, щоб відфільтрувати дані якомога раніше

Trivial plan optimization

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

Full optimization: search 0

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

Full optimization: search 1

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

Full optimization: search 2

Це самий останній етап оптимізації, на якому в будь-якому випадку буде знайдений той чи інший план виконання запиту.

На етапі query optimization перед тим, як передати знайдений, тобто підсумковий план запиту на виконання, цей план поміщається в кеш планів, для випадків, якщо цей же запит найближчим часом буде використаний повторно.

Query execution

Результатом попереднього етапу є план виконання запиту, тобто на вході в даний етап ми маємо готовий план виконання, який необхідно реалізувати.

Query execution призначений саме для цього, тобто на даному етапі реалізується план виконання запиту.

Виглядає це приблизно наступним чином, в ході виконання плану і обробки конкретних кроків query execution запитує у підсистеми сховища (storage engine) дані з базових таблиць, які потрібні для формування результуючого набору даних.

Потім він перетворює ці дані у формат результуючого набору даних і повертає цей набір клієнту.

Всі дії, пов’язані з блокуваннями, із записами в файл даних і журнал транзакцій, виконуються на стороні підсистеми сховища, тобто в storage engine.

Висновки (загальна схема)

Таким чином, ми розуміємо, що починаючи з моменту, коли sql запит надійшов на сервер, всередині microsoft sql server запускається складний механізм, який обробляє цей sql запит.

Іншими словами, між тим моментом, коли ми послали sql запит на сервер і моментом, коли ми побачили запитувані дані, буде виконана величезна робота.

Щоб підсумувати все вищесказане, давайте подивимося на схему, на якій зображено верхньорівневе представлення всього процесу обробки sql запиту в microsoft sql server.

На сьогодні це все, сподіваюся, матеріал був вам корисний, поки!