Оптимізація запитів у ORACLE за допомогою плану виконання - Life in Code
Відразу уточню, що описуватиму на прикладі використання фрі утиліти OraDeveloper Studio. Чому? Тому що звичайними запитами цього зробити не вдалося, а часу та бажання розбиратися не було, якщо вже є спосіб простіше. 😉
Отже, навіщо це взагалі потрібно? Опишу вам конкретний приклад, через який я був змушений проводити оптимізацію.
Завдання - вантажити в базу десятки тисяч рядків даних. Для кожного рядка необхідно заздалегідь по базі знайти додаткові дані одним досить громіздким запитом (4 таблиці через джойни). Проблема - завантаження 15 тисяч рядків займає 8-9 годин. Тому що за умовами завдання завантажувати треба часто, а не один раз на п'ятирічку… Загалом, треба довести час до прийнятного.
Що я зробив? 1. З'ясував, що гальмує саме селект (дані вставляються та оновлюються в таблицях, де купа рядків і частина таблиць не має ні індексів, ні ключів — звідси й сумніви у вині селекту). 2. Перевірив наявність індексів на полях, що використовуються запитом. Додав відсутніх. 3. Запитав допомоги у знаючих. 🙂
Обізнані порадили проаналізувати план виконання запиту і пояснили, як це зробити в OraDev. Створюємо нове вікно запиту (Ctrl+N). Копіюємо у нього наш запит. Тиснемо Alt+G. Вибираємо вже існуючу чи створюємо нову таблицю плану. Після виконання з'явиться дерево плану виконання. Самостійно і без півлітри в ньому розібратися не так просто. 😉
Що ж нас цікавить у цьому дереві? Нас цікавлять вузли (кроки), для яких вказано великий Cost кроку. Ціну кроку ви можете побачити у властивостях кроку (у мене віконце властивостей постійно відкрите і тому мені треба лише вибрати потрібний крок; а вам можепотрібно вибирати властивості по правому кліку на кроці). Шукаємо повільний крок (найвищий вузол, корінь дерева плану, в розрахунок особливо не беремо - там буде вказана загальна ціна запиту, а ми вже знаємо, що проблема саме в цьому запиті). Знайшли? Тепер дивимося, з якою таблицею, якими її полями та з якою кількістю рядків працює крок — це є у властивостях та імені кроку. Дивимось і думаємо, чому у нас так повільно? У мене, наприклад, один із кроків працював із 4000 записів замість одного-трьох записів (не тисяч). Такого бути не повинно було в принципі — я ж обмежую вибірку саме для того, щоб вибирати з потрібного діапазону, а не купи зайвого барахла. Уважно придивившись до умови джойна, я помітив, що втратив одне з полів. Додав поле у запит і все стало на свої місця. Ціна запиту (повна) зменшилася з 531 до 6. 🙂