Ответ
В PostgreSQL по умолчанию создаётся индекс типа B-tree (B-дерево), если в команде CREATE INDEX не указан другой метод доступа.
Почему B-tree? Это сбалансированное дерево, оптимальное для широкого спектра операций:
- Проверка равенства (
=) - Диапазонные запросы (
>,<,BETWEEN) - Сортировка (
ORDER BY) - Поиск по префиксу (
LIKE 'abc%') - Поддержка уникальных ограничений и
NULLзначений.
Синтаксис:
-- Создаст B-tree индекс по умолчанию
CREATE INDEX idx_user_email ON users(email);
-- Явное указание типа B-tree (эквивалентно строке выше)
CREATE INDEX idx_user_email ON users USING btree (email);Альтернативные типы индексов (требуют явного указания):
HASH— для операций строгого равенства.GIN— для полнотекстового поиска и JSONB.GiST/SP-GiST— для геоданных и сложных типов.BRIN— для очень больших таблиц с коррелированными данными.
Ответ 18+ 🔞
А, слушай, вот тебе наглядный пример, как всё просто, а потом оказывается, что под капотом — целый ёперный театр. Берёшь ты команду CREATE INDEX в Постгресе и думаешь: "Ну, создам я индекс, и всё". А он тебе, сука, по умолчанию B-tree лепит! Блядь, как будто других типов не существует!
Ну, а че? B-tree — это как универсальный солдат, швейцарский нож, блядь. Он для всего сгодится: и если тебе надо найти что-то конкретное (WHERE email = 'вася@пупкин.ру'), и если выбрать всё "от сих до сих" (WHERE age BETWEEN 18 AND 25), и даже если отсортировать по полю. В общем, палочка-выручалочка, ёпта. Поэтому его и выбрали дефолтным — чтобы распиздяй, который в индексах не шарит, хотя бы не накосячил с самого начала.
Вот смотри, пишешь ты:
CREATE INDEX idx_user_email ON users(email);И думаешь: "Всё, я молодец". А под капотом-то происходит магия: Постгрес сам, как хитрая жопа, дописывает туда USING btree. Полная запись, которую он выполняет, выглядит так:
CREATE INDEX idx_user_email ON users USING btree (email);Одно и то же, блядь! Просто в первом случае он за тебя думает. Ну, спасибо, конечно, но иногда это доверия ебать ноль вызывает.
А теперь главное, блядь, не обосраться! Потому что если тебе нужна не эта универсальная дубина, а что-то точечное — надо явно указать. А то будешь потом охуевать, почему хеш-индекс не работает для LIKE.
Вот тебе краткий разбор полётов, что ещё есть в арсенале, кроме этого вездесущего B-tree:
HASH— Это для тупых, но быстрых проверок на равенство. Только=. Спросил — получил. Всё. Для диапазонов — нихуя не годится. Как молоток: гвоздь забить — идеально, шуруп закрутить — пиздец.GIN— Вот это уже для интеллектуалов. Полнотекстовый поиск, JSONB-поля, массивы. Когда тебе надо искать внутри данных, а не по ним целиком. Мощная штука, но и кушает много.GiST/SP-GiST— Для всяких гео-заморочек, поиска по интервалам, по сложным типам данных. Если работаешь с координатами или чем-то таким — тебе сюда. Иначе даже не лезь, а то запутаешься, как мартышлюшка.BRIN— А это для совсем уж здоровых дядек, у которых таблицы размером с овердохуища. Он не по каждому значению строит индекс, а по блокам. Если данные в таблице лежат упорядоченно (например, по дате), то он может быть охуенно эффективным и маленьким. Но если данные вразнобой — это просто выброшенное время и место.
Короче, мой совет: если не знаешь, что выбрать — оставь B-tree, не прогадаешь. Но если уже упёрся в конкретную, узкую задачу — читай документацию и выбирай специализированный инструмент. А то будет как с Герасимом и Муму — возьмёшь и утопишь производительность в пизду, потому что не подумал.