Logs

Останні нотатки

Чекліст при виборі індексів

2 хв читання

Інформація стосується будь-якої БД де використовуються B-Tree індекси.

Index Selectivity

Selectivity характеризує те наскільки малу частину даних можна отримати фільтруючи по одному значеню. Чи більше даних дозволяє зрізати фільтр — тим у нього краща Selectivity.

  • найбільш ефективні індекси мають Selectivity < 10%. Якщо фільтр зрізає ледь 50% даних (Low-cardinality fields, boolean flags) — ефективність такого індекса під питанням і БД може вирішити не використовувати індекс взагалі
  • співвідношення між кількістю прочитаних ключів індекса (Keys Examined) та кількістю результатів (Rows Returned). В ідеалі співвідношення близьке 1:1 (ну або 100%), тобто БД повертає всі результати, що були знайдені в індексі. Чим більший розрив — тим більше БД витрачає ресурсів вхолосту. Наприклад при співвідношенні 4200:42 базі даних довелось обробити 4200 записи, хоча в дійсності потрібно було лише 42

ESR Rule

Це правило описує в якому порядку слід перераховувати поля в композитних (compound) індексах.

  • Equality: Поля по яким відбувається пошук по точному співпадінню
    • важливо: БД важко шукати по умовам !=. По суті цей оператор равносильний пошуку по ренжу. В дійсності він гірший так як БД читає весь індекс, а не конкретні його проміжки
  • Sort: Поля по яким відбувається сортування
  • Range: Поля по яким шукають інтервалами (>, <, IN, !=, NOT IN)

Equality поля дозволяють зрізати кількість даних для обробки. Sort поля мають йти перед Range — це дасть можливість використовувати сортування індексу. Якщо Sort поля будуть йти після Range, то на вхід до сортування ми отримаємо N шматочків даних, кожний зі своїм сортуванням і БД доведеться пересортовувати їх в пам’яті в один загальний порядок.

Використання префіксів індексів

Більшість БД при використанні композитних (compound) індексів дозволяють шукати по першим N полям таких індексів. Періодично є соблазн створити композитний індекс щоб задовільнити додтаково якісь інші запити за рахунок використання префіксу. В таких випадках слід добре подумати і врахувати вище наведені правила.

Неоптимальний індекс може шкодити загальному перформансу БД і витісняти з RAM кеш іншої корисної інформації (через те, що БД має завантажити в пам’ять більшу частину індексу, ніж треба для запиту). Краще зробити оптимальний композитний ідекс і окремо додати індекс по одному полю більше місця на диску це менша проблема ніж відсутність потрібних даних в RAM. Звісно, кожний випадок унікальний і тут все “it depends”.

Вигляд графа