Як обговорити повільний план запиту з DBA англійською мовою

Розмова з адміністратором бази даних (DBA) про повільний запит вимагає певного словника — ви не просто кажете « це повільно », ви описуєте, що планувальник запиту вибрав зробити і чому цей вибір може бути неправильним. У цьому підручнику ви знайдете англійську фразу для обговорення планів запиту, використання індексів і пропозицій щодо оптимізації.

Ключовий словник

** План запиту ** — послідовність кроків, які рушій бази даних обирає для виконання запиту, зокрема, які індекси він використовує і у якому порядку він з’ єднує таблиці.

• “Чи можете ви подивитися на план запиту для цього запиту звіту? Це вибір послідовного сканування, де я очікував індексного сканування.”*

** Послідовне сканування (seq scan) ** — читання кожного рядка таблиці для пошуку збігів, що зазвичай є повільним у великих таблицях і часто є ознакою відсутності корисного індексу.

• “Планувальник виконує послідовне сканування таблиці з 40 мільйонами рядків, що пояснює, чому цей запит займає 12 секунд.” *

** Сканування індексу ** — використовувати індекс для переходу безпосередньо до відповідних рядків замість сканування всієї таблиці, що зазвичай набагато швидше для вибіркових запитів. “Якщо ми додали індекс на created_at, план переключився на сканування індексу і запит впав нижче 100 мс.”

** Оцінка кількісної ваги ** — оцінка бази даних щодо кількості рядків, які буде повернено за допомогою кроку у запиту, що сильно впливає на вибір плану.

• “Оцінка планувальника щодо кількості рядків для цього з’ єднання є дуже неправильною — він очікує 200 рядків, але фактичний результат становить 2 мільйони, саме тому він вибрав вкладений цикл замість геш- з’ єднання.” *

** Статистика (статистика таблиць) ** — метадані, які зберігаються у базі даних щодо розподілу значень у таблиці, використовуються для створення оцінок кардиналізації; застаріла статистика часто призводить до поганих планів.

• “Статистика цієї таблиці не оновлюється з часу останнього масового імпорту, отже, планувальник працює за застарілими припущеннями. Чи можемо ми провести аналіз, перш ніж подивитись на це далі?»*

Звичайні фрази

• «Ось вивід EXPLAIN ANALYZE — планувальник вибирає seq сканування на таблиці замовлень.»
• «Фактичні рядки, що повертаються, набагато вищі за оцінку, що свідчить про те, що статистика застаріла»
• «Чи допоможе додавання складного індексу на (customer_id, created_at) тут?»
• «Це з’єднання є вкладеною петлею з 2 мільйонами рядків — це, ймовірно, наше вузьке місце»
• Чи можемо ми запустити ANALYZE на цій таблиці, перш ніж ми поглинемося далі в план?»

Приклади речення

Відкриття розмови з адміністратором бази даних за допомогою спільного використання конкретних доказів:

• “Я запустив EXPLAIN ANALYZE для цього запиту, і він витрачає 9 з 11 секунд на послідовне сканування таблиці events. Чи ви б були відкриті до обговорення, чи має сенс індекс на (user_id, event_type) тут?»*

Опис невідповідності між оцінкою і фактичним:

• “За оцінками планувальника, це з’ єднання поверне близько 500 рядків, але EXPLAIN ANALYZE показує, що насправді буде повернуто 1, 2 мільйона. Цей прогал, ймовірно, тому він вибирає вкладений цикл замість геш-з’єднання.”*

Пропонування конкретного наступного кроку, а не нечітка скарга: “Замість того, щоб просто стверджувати, що це повільно, я б хотів запропонувати перевірити складний індекс і порівняти план до і після — я можу скласти порівняння до/після EXPLAIN ANALYZE, якщо це буде корисним.”

Підтримка після виправлення:

• “Після додавання індексу, план тепер використовує сканування тільки індексу, а час запиту скоротився з 11 секунд до 80 мілісекунд. Я долучив до планів до і після для посилання.”*

Професійні поради

• Завжди приносіть **справжній вивід EXPLAIN ANALYZE **, а не просто опис — адміністратори баз даних хочуть прочитати план самі, і вставлення його показує, що ви вже зробили діагностичну роботу.
• Використовуйте ** « планувальник вибрав » ** або ** « планувальник робить вибір » ** замість « база даних робить » — ця форма правильно приписує рішення оптимізатору запиту, який насправді буде розглядати рішення адміністратора бази даних.
• Вказуйте на ** розрив між оціненим і фактичним рядками **, коли ви його побачите — це одна з найпоширеніших причин, яку DBAs шукають першими.
• Запропонуйте конкретний, перевіряний наступний крок («перевірити складний індекс на X»), а не просто описуйте проблему — це показує, що ви пропонуєте гіпотезу, а не просто просите когось іншого виправити її.
• Після виправлення, поділіться порівняннями до/ після — це закриває петлю і допомагає створити спільне розуміння того, що працювало.

Практичні вправи

1. Написати речення, яке відкриває розмову з адміністратором бази даних, у якому буде вказано певне число з виводу EXPLAIN ANALYZE.
2. Напишіть речення, у якому буде описано розрив між оцінкою і фактичною кількістю рядків.
3. Написати повідомлення про результати, що стосуються зміни індексу.

Наприклад, слово «навигатор» (англ. navigator) означає «технічний навігатор»

Успішне обговорення складних технічних концепцій — таких як повільні запиту — до DBA вимагає більше, ніж просто зауваження проблеми. Це про те, щоб точно сформулювати свої зауваження, використовуючи правильну термінологію і продемонструвати, що ви розумієте * чому * ця проблема має значення. Для не-рідних англомовних, це може відчуватися особливо пригнічуючим, особливо коли справа доходить до спеціалізованого жаргону. Давайте сконцентрируемся на побудове впевненості в тому, що висловимо ці питання чітко і професійно.

Однією з найбільших перешкод часто є перетворення деталей з ваших початкових спостережень у формат, який адміністратор бази даних легко зрозуміє. Не просто скажіть « цей запит повільний ». Замість цього спробуйте визначити, що ви спостерігали, і сформулювати це з точністю. Наприклад, замість того, щоб сказати « план пояснення показує повне сканування таблиць », розгляньте можливість формулювання так: « Вивід EXPLAIN ANALYZE вказує на потенційну проблему з використанням індексу; ми бачимо повне сканування таблиць на таблиці orders для цього конкретного запиту. » Це демонструє, що ви дійсно переглянули дані і не просто скаржитеся на швидкість.

При обговоренні виходу EXPLAIN ANALYZE, важливо використовувати такі терміни як «вартість», «оцінка» проти «реальна» і «вигода». DBA буде шукати розбіжності між тим, що база даних передбачала і що вона фактично зробила. Такі фрази, як «оцінена вартість значно вища, ніж фактичний час виконання» або «оптимізатор запиту, здається, неправильно оцінює розподіл даних» є набагато ефективнішими, ніж нечіткі твердження про продуктивність. Крім того, розуміння таких термінів, як «пошук індексу» проти «сканування індексу» - і можливість пояснити * чому * один може бути кращим за інший - демонструє глибший рівень знань.

Нарешті, пам’ятайте, що чітке спілкування не тільки про словниковий запас; це також про структуру. Добре написаний опис запитів на захоплення, що описує проблему, ваші спостереження з EXPLAIN ANALYZE і будь-які запропоновані рішення є безцінними. Такі фрази, як « Я підозрюю, що стратегія індексування є неефективною » або « Давайте розглянемо, чи додавання складного індексу до [стовпчиків] зменшить цю проблему », є набагато ефективнішими, ніж просто вказати « Цей запит потребує оптимізації ». Ці ретельно складені речення демонструють ваш активний підхід і бажання співпрацювати з адмініструвачем бази даних.