При спробі зрозуміти, як виконується оператор SQL, іноді рекомендується переглянути план пояснення. Який процес слід пройти при тлумаченні (осмисленні) плану пояснення? Що має виділятися як: "О, це чудово працює?" проти "О ні, це не правильно".
Відповіді:
Я здригаюся, коли бачу коментарі, що повні таблиці є поганими, а доступ до індексу хорошим. Повне сканування таблиці, сканування діапазону індексів, швидке сканування повного індексу, вкладені цикли, об'єднання об'єднань, хеш-з'єднання тощо - це просто механізми доступу, які аналітик повинен зрозуміти і поєднати зі знанням структури бази даних та ціллю запиту в для досягнення будь-якого змістовного висновку.
Повне сканування - це просто найефективніший спосіб зчитування значної частини блоків сегмента даних (таблиці або таблиці (підрозділу)), і, хоча це часто може вказувати на проблему продуктивності, це лише в контексті про те, чи є це ефективним механізмом для досягнення цілей запиту. Якщо виступати як сховище даних і хлопець з BI, мій номер попередження про продуктивність - це метод доступу на основі індексу та вкладений цикл.
Отже, для механізму читання пояснювального плану документація Oracle є гарним посібником: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Також добре прочитайте Посібник з налаштування продуктивності.
Також маємо google для "зворотного зв'язку щодо потужності", методики, при якій план пояснення може бути використаний для порівняння оцінок значущості на різних етапах запиту з фактичними значеннями, які зазнали під час виконання. Я вважаю, що автором методу є Вольфганг Брайтлінг.
Отже, підсумок: зрозумійте механізми доступу. Зрозумійте базу даних. Зрозумійте намір запиту. Уникайте емпіричних правил.
Ця тема занадто велика, щоб відповісти у такому питанні. Вам слід трохи зачитати Посібник з налаштування продуктивності Oracle
Два наведені нижче приклади показують ПОВНЕ сканування та ШВИДКЕ сканування за допомогою INDEX.
Найкраще зосередитися на своїй вартості та потужності. Переглядаючи приклади, використання індексу зменшує вартість запуску запиту.
Це дещо складніше (і я не маю 100% дескриптора на ньому), але в основному вартість є функцією вартості процесора та вводу-виводу, а потужність - це кількість рядків, які Oracle очікує проаналізувати. Зменшення обох - це добре.
Не забувайте, що на вартість запиту може впливати ваш запит та модель оптимізатора Oracle (наприклад: ВАРТІСТЬ, ВИБІР тощо) та як часто ви запускаєте статистику.
Приклад 1:
СКАНУВАТИ http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Приклад 2 з використанням індексів:
ІНДЕКС http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
І, як уже пропонувалося, слідкуйте за ТАБЛИЧНИМ скануванням. Як правило, цього можна уникнути.
Шукати такі речі, як послідовне сканування, може бути дещо корисним, але реальність полягає в цифрах ... за винятком випадків, коли цифри - це лише оцінки! Що, як правило, набагато корисніше, ніж перегляд плану запитів, це перегляд фактичного виконання . У Postgres це різниця між EXPLAIN та EXPLAIN ANALYZE. EXPLAIN ANALYZE фактично виконує запит і отримує реальну інформацію про час для кожного вузла. Це дозволяє побачити, що насправді відбувається, а не те, що планує планувальник . Багато разів ви виявите, що послідовне сканування взагалі не є проблемою, натомість це щось інше у запиті.
Інший ключ - це визначення справжнього дорогого кроку. Багато графічних інструментів використовуватимуть стрілки різного розміру, щоб вказати, скільки коштують різні частини плану. У такому випадку просто шукайте сходинки, на які входять тонкі стрілки і товста стрілка, що йде. Якщо ви не використовуєте графічний інтерфейс, вам потрібно буде розглянути цифри та знайти, де вони раптом стають набагато більшими. Трохи попрактикувавшись, досить легко вибрати проблемні зони.
Дійсно для таких питань, найкраще зробити ASKTOM . Зокрема, його відповідь на це питання містить посилання на Інтернет-документ Oracle, де пояснюється багато таких правил.
Майте на увазі одне, що пояснення планів - це справді найкращі здогадки.
Було б непогано навчитися користуватися sqlplus та експериментувати з командою AUTOTRACE. Маючи певні тверді цифри, ви можете прийняти кращі рішення.
Але вам слід АСКТОМУВАТИ. Він все про це знає :)
Вихідні дані пояснюють, скільки часу пройшов кожен крок. Перше, що потрібно - знайти кроки, які тривали довгий час, і зрозуміти, що вони означають. Такі речі, як послідовне сканування, говорять вам, що вам потрібні кращі індекси - це здебільшого питання дослідження вашої конкретної бази даних та досвіду.
Одне "О ні, це не так" часто має форму сканування таблиці . Сканування таблиць не використовує спеціальних індексів і може сприяти очищенню кожного корисного в кешах пам'яті. Наприклад, у postgreSQL ви побачите, що це виглядає так.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
Іноді сканування таблиць ідеально підходить, скажімо, за допомогою індексу для запиту рядків. Однак це один із тих візерунків з червоним прапором, який ви, здається, шукаєте.
В основному, ви дивитесь на кожну операцію і перевіряєте, чи мають операції «сенс», враховуючи ваші знання про те, як вона повинна працювати.
Наприклад, якщо ви приєднуєте дві таблиці, A та B у відповідних стовпцях C та D (AC = BD), і ваш план показує кластерне сканування індексу (термін SQL Server - не впевнений у терміні оракула) на таблиці A, потім вкладений цикл приєднується до ряду кластеризованих індексів, що шукаються в таблиці B, ви можете подумати, що виникла проблема. У цьому випадку ви можете очікувати, що движок виконає пару сканування індексів (над індексами в об'єднаних стовпцях) з наступним об'єднанням. Подальше дослідження може виявити погані статистичні дані, що змушують оптимізатор вибирати шаблон з’єднання або індекс, який насправді не існує.
подивіться на відсоток часу, проведеного в кожному підрозділі плану, і подумайте, що робить двигун. наприклад, якщо це сканування таблиці, розгляньте можливість розміщення індексу на полі (полях), для якого виконується сканування
В основному я шукаю сканування індексу або таблиці. Зазвичай це говорить мені, що мені не вистачає індексу у важливому стовпці, який знаходиться в операторі where або join.
З http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
Якщо ви бачите щось із наведеного в плані виконання, вам слід розглянути їх як попереджувальні знаки та дослідити їх на предмет можливих проблем із продуктивністю. Кожен з них є менш ніж ідеальним з точки зору продуктивності.
* Index or table scans: May indicate a need for better or additional indexes. * Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement. * Filter: Remove any functions in the WHERE clause, don't include wiews in your Transact-SQL code, may need additional indexes. * Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?Не завжди вдається їх уникнути, але чим більше ви можете їх уникнути, тим швидшою буде продуктивність запитів.
(Ви, мабуть, теж хочете ознайомитися з деталями:
Сканування таблиці декількох великих таблиць
Використання унікального індексу
Індекс включає всі обов’язкові поля
Приблизно в 90% проблем із продуктивністю, які я бачив, найпростіший виграш - це розбити запит із безліччю (4 або більше) таблиць на 2 менші запити та тимчасову таблицю.