⚡️ Индексы в базах данных: как заставить запросы летать
Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.
Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.
✅ Зачем нужны:
* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).
❌ Чем платим (минусы):
* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.
🛠 Чек-лист: индексировать или нет?
🟢 Обязательно индексируем:
1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).
🔴 НЕ индексируем:
1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.
💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.
#db
👉 @database_info
Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.
Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.
✅ Зачем нужны:
* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).
❌ Чем платим (минусы):
* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.
🛠 Чек-лист: индексировать или нет?
🟢 Обязательно индексируем:
1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).
🔴 НЕ индексируем:
1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.
💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.
#db
👉 @database_info