Перейти на PRO

Почему важен порядок полей в составном (composite) индексе базы данных?

Тип вопроса: Базы данных Вероятность: 10% Категория: Golang Разработчик

Ответ

Да, порядок полей в составном индексе критически важен для производительности запросов. Это связано с тем, как базы данных используют такие индексы.

Правило левого префикса (Left-Prefix Rule)

Составной индекс можно сравнить с отсортированным телефонным справочником, где записи упорядочены сначала по Фамилии, а затем по Имени.

  • Вы легко найдёте всех людей с фамилией Иванов.
  • Вы легко найдёте конкретного Иванова Ивана.
  • Но вы не сможете эффективно найти всех людей с именем Иван, не перебирая весь справочник, потому что они разбросаны по разным фамилиям.

Точно так же работает и составной индекс. Он может быть эффективно использован только тогда, когда условия в WHERE соответствуют левому префиксу индекса, то есть первому полю, первым двум полям, первым трём и так далее.

Пример

Допустим, у нас есть таблица users и мы создаём составной индекс по полям city, status и created_at.

CREATE INDEX idx_users_city_status_created ON users (city, status, created_at);

✅ Этот индекс будет эффективно использоваться для запросов:

-- 1. Используется первое поле индекса (city)
SELECT * FROM users WHERE city = 'Москва';

-- 2. Используются первые два поля (city, status)
SELECT * FROM users WHERE city = 'Москва' AND status = 'active';

-- 3. Используются все три поля (city, status, created_at)
SELECT * FROM users WHERE city = 'Москва' AND status = 'active' AND created_at > '2023-01-01';

-- 4. Порядок в WHERE не важен, важен состав полей
SELECT * FROM users WHERE status = 'active' AND city = 'Москва';

❌ Этот индекс будет НЕэффективен или бесполезен для запросов:

-- Пропущено первое поле (city). Индекс не используется для поиска.
SELECT * FROM users WHERE status = 'active';

-- Пропущено второе поле (status). Индекс используется только по `city`.
SELECT * FROM users WHERE city = 'Москва' AND created_at > '2023-01-01';

Как выбирать порядок полей?

  1. Равенство > Диапазон: Сначала ставьте поля, которые будут использоваться в условиях на точное равенство (=, IN), а затем поля для диапазонных условий (>, <, BETWEEN). Как только планировщик встречает диапазон, использование последующих полей индекса становится неэффективным.

  2. Селективность: На первые позиции ставьте поля с высокой селективностью (большим количеством уникальных значений, например, user_id). Поля с низкой селективностью (например, is_deleted с двумя значениями true/false) лучше ставить в конец.

  3. Частота запросов: Анализируйте ваши самые частые и медленные запросы и стройте индекс под них.

Вывод: Правильный порядок полей в составном индексе позволяет базе данных максимально быстро сужать область поиска, что напрямую влияет на скорость выполнения запросов.

Ответ 18+ 🔞

А, вот это, блядь, тема! Порядок полей в составном индексе — это как, сука, фундамент для производительности. Если накосячить тут, то запросы будут тормозить так, что волосы дыбом встанут. Это не просто рекомендация, это, блядь, закон.

Правило левого префикса, или «С чего начинается родина?»

Представь себе, что составной индекс — это вот такой вот, блядь, бумажный телефонный справочник, который отсортирован сначала по Городу, потом по Статусу, а потом по Дате регистрации.

  • Найти всех в Москве? Легко, открыл нужную страницу и пошёл.
  • Найти всех активных в Москве? Тоже ок, они там все кучкой.
  • А вот найти всех активных по всей стране? Это пиздец, братан. Тебе придётся листать всю эту хуйню от корки до корки, потому что активные пользователи размазаны по всем городам.

Индекс работает ровно так же. Он эффективен, только если ты в запросе используешь поля с самого начала, по порядку. Первое, первое и второе, первое, второе и третье. Как только пропустил шаг — всё, поезд ушёл.

Разбор полётов на примере

Допустим, мы наколхозили индекс на три поля: city, status, created_at.

CREATE INDEX idx_users_city_status_created ON users (city, status, created_at);

✅ Запросы, от которых индекс просто обоссытся от счастья:

-- 1. Используем только первый столб (city). Всё чётко.
SELECT * FROM users WHERE city = 'Москва';

-- 2. Используем первые два (city, status). Идеально.
SELECT * FROM users WHERE city = 'Москва' AND status = 'active';

-- 3. Используем все три! Мечта, а не запрос.
SELECT * FROM users WHERE city = 'Москва' AND status = 'active' AND created_at > '2023-01-01';

-- 4. Порядок в WHERE — похуй. Главное, что в индексе они есть.
SELECT * FROM users WHERE status = 'active' AND city = 'Москва';

❌ Запросы, от которых индекс скажет «иди нахуй» и пойдёт делать полный перебор:

-- Э, дружок, а где первое поле (city)? Без него я нихуя не могу.
SELECT * FROM users WHERE status = 'active';

-- Ну city-то есть, а вот status пропущен. Я смогу отфильтровать только по городу, а дальше — вручную по дате, извини.
SELECT * FROM users WHERE city = 'Москва' AND created_at > '2023-01-01';

Так как же, блядь, правильно расставить поля?

  1. Равенство вперёд, диапазоны — на свалку. Сначала ставь поля, по которым ищешь точное совпадение (=, IN). Потом уже те, где диапазоны (>, <). Как только в запросе появляется «больше-меньше», использование следующих полей индекса ломается, как хрустальная ваза в борделе.

  2. Селективность — твой бог. Первыми идут поля, где значений дохуя и все разные (типа user_id или email). А всякую хуйню вроде is_deleted (где всего true/false) — пихай в конец, если только она не критична.

  3. Думай головой, а не жопой. Проанализируй, какие запросы у тебя самые частые и самые тяжёлые. Под них и затачивай индекс. Нет волшебной таблетки, есть только понимание своей собственной, ебучей, бизнес-логики.

Короче, вывод простой, как три копейки: Порядок полей в индексе — это не просто прихоть, а, блядь, руководство к действию для базы данных. Правильно поставил — запрос летает. Накосячил — сиди и жди, пока этот уёбок всё перелопатит. Выбирай.

© ХакСобесов, 2026
support@hacksobesov.com