Як обговорювати базу даних Index Tuning англійською мовою

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

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

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

** Селективність ** — наскільки ефективно стовпчик (або комбінація стовпчиків) сужає набір результатів; стовпчик з високою селективністю є сильним кандидатом на індексування, у той час як стовпчик з низькою селективністю (наприклад, булівська) часто не варто індексувати окремо.

• “Колонка status має низьку селективність — це одне з трьох значень серед десяти мільйонів рядків, тому індексування її самої не допоможе. Об’єднання його з created_at в складеному індексі буде.”*

** Складений індекс ** — індекс, що містить декілька стовпчиків, корисний, якщо запиту послідовно фільтрують або впорядковують за однією і тією ж комбінацією полів, порядок стовпчиків має значення для того, які запити можуть використовувати цей індекс. “Ми потребуємо складний індекс на (customer_id, created_at), у цьому порядку, оскільки кожен запит фільтрує спочатку за клієнтом, а потім сортує за датою.”

** Розширення запису (надмірні витрати на індексування) ** — додаткові витрати, які виникає при кожному вставленні, оновленні і вилученні індексу, компромісну сторону додавання індексу, яку слід зважувати з перевагами на стороні читання. “Ця таблиця отримує багато записів, отже новий індекс не є вільним — кожен вставлений індекс тепер повинен оновлювати три індекси замість двох, і ми повинні виміряти цей запис перед тим, як його зафіксувати.”

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

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

• «Що показує план запиту — послідовне сканування, або існуючий індекс вже використовується неефективно?»
• Чи є ця колонка достатньо вибірковою, щоб варто було індексувати її самостійно?»
• Чи має це бути складний індекс, і якщо так, то який порядок стовпців відповідає нашим фактичним шаблонам запиту?
• «Що таке гравітація, якою ми користуємося, щоб описати цю величину?»
• Чи можемо ми зробити це покривним індексом, щоб уникнути пошуку додаткових таблиць повністю?»

Приклади висловлювань

Запропонування індексу у перегляді швидкодії:

• “План запиту підтверджує повне послідовне сканування цієї таблиці для запиту, який ми виконуємо постійно. Додавши складний індекс на (user_id, status), можна перетворити його на індексне сканування — я перевірив це в стаджі та скоротив час запиту з 800 мс до 12 мс.”*

Відмовляючись від надмірно охочих пропозицій щодо індексування:

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

Пояснюючи компроміс команді:

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

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

• Завжди показувати ** план запиту **, а не тільки спостережену затримку, при запропонуванні індексу — « записи повільні » не переконливі без виводу EXPLAIN, що показує чому.
• Обговоріть ** вибірковість ** перед тим, як запропонувати індекс для стовпчика з низькою кардиналістю — це запобігає як марному індексуванню, так і розмові « чому це не допомогло ».
• Явно вкажіть запланований ** порядок стовпчиків **, коли пропонуєте ** складний індекс ** — порядок визначає, які запити можуть його використовувати, і якщо він буде неправильним, індекс буде марним.
• Назвемо вартість ** підсилення запису ** поряд з перевагою зчитування в будь- якій пропозиції індексування — односторонній хід, який ігнорує вартість запису, є легкою мішенню для скептично налаштованого рецензента, і це правильно.

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

1. Напишіть речення, у якому пояснюється, що план запиту показує щодо використання індексу.
2. Опишете селективність вашими словами за допомогою прикладу з низькою кардиналістю.
3. Пояснити компроміс, який складний індекс вводить у шлях запису.

Навигація Нуанс: Специфічний словник для обговорення налаштування індексу

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

Один з найпоширеніших сценаріїв під час перегляду коду. Уявіть, що ви отримали такий коментар щодо запиту на звантаження: « Цему запиту може бути корисним індекс на customer_id ». Простим перекладом може бути « таблиця має бути швидшою ». Але це не відповідає дійсності. Замість цього, більш ефективною відповіддю було б: «Це хороша пропозиція. Чи можете ви розібратися у * вибірковості * цього запиту? Зокрема, який відсоток рядків фільтрує стовпчик customer_id у цьому конкретному контексті?” Зауважте, що використання таких термінів, як « вибірковість », негайно піднімає обговорення вище базового твердження про необхідність індексу і змушує оригінального автора (або рецензента) надати більш докладну інформацію. Аналогічно, ви можете почути, як хтось каже: « Нам слід оптимізувати таблицю orders для запитів на звіти ». Це можна поліпшити, додавши: « Давайте розглянемо * план запиту *, створений під час виконання цього запиту. Чи використовується існуючий індекс ефективно, чи виконується повне сканування таблиці? Зрозуміти план запиту допоможе нам визначити, чи індекс на order_date забезпечить значний підйом продуктивності.”

Інша ситуація виникає в розмовах Slack при обговоренні потенційних змін до схеми бази даних. Розробник може написати: « Додавши індекс до product_name, ви пришвидшите процес ». Знову ж таки, це занадто нечітке. Кращий підхід був би: «Щоб переконатися, що ми приймаємо правильне рішення, розглянемо компроміс. Хоча індексування product_name може поліпшити швидкість читання для запитів, що фільтрують за назвою продукту, це може негативно вплинути на швидкість запису - зокрема, вставлення або оновлення рядків в цьому стовпці також вимагатиме оновлення індексу. Давайте також розглянемо загальний * співвідношення читання/ запису * цієї таблиці; чи є вона переважно складною для читання або складною для запису?» Це демонструє більш складне розуміння системи бази даних і підкреслює важливість розгляду обох аспектів під час запропонованого індексу.

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