Каковы преимущества и недостатки Hash индекса?

«Каковы преимущества и недостатки Hash индекса?» — вопрос из категории Базы данных, который задают на 24% собеседований PHP Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Hash-индекс хранит пары «ключ-значение», где ключ — это хэш-значение от индексируемого столбца, а значение — указатель на строку в таблице. Он предназначен для очень специфичных сценариев.

Преимущества Hash индексов:

  • Скорость поиска по точному совпадению: В идеальном случае (без коллизий) поиск имеет сложность O(1). Для оператора = он может быть быстрее, чем B-Tree.
  • Эффективность для уникальных значений: Идеально подходит для поиска по первичному ключу или другим уникальным столбцам, где выполняются только операции равенства.

Недостатки и ограничения Hash индексов:

  • Не поддерживает диапазонные запросы: Нельзя использовать для операторов >, <, BETWEEN. Индекс бесполезен для ORDER BY и GROUP BY.
  • Не поддерживает префиксный поиск: Не работает с оператором LIKE (даже с LIKE 'prefix%').
  • Проблема коллизий: При коллизиях хэшей производительность деградирует, и СУБД приходится разрешать их (например, через цепочки).
  • Ограниченная поддержка: Не все СУБД предлагают Hash-индексы. Например, в PostgreSQL они существуют, но считаются менее надежными, чем B-Tree, и не записываются в WAL по умолчанию. В MySQL они поддерживаются только для движка таблиц Memory/Heap.

Пример использования в PostgreSQL (с оговорками):

-- Создание Hash индекса
CREATE INDEX idx_users_email_hash ON users USING HASH (email);

-- Запрос, который МОЖЕТ (но не гарантированно) использовать Hash индекс эффективно
SELECT * FROM users WHERE email = 'alice@example.com';

-- Запросы, для которых Hash индекс БЕСПОЛЕЗЕН:
SELECT * FROM users WHERE email LIKE 'ali%'; -- Префиксный поиск
SELECT * FROM users WHERE created_at > NOW() - INTERVAL '1 day'; -- Диапазон
SELECT * FROM users ORDER BY email; -- Сортировка

Вывод: Hash-индекс — это узкоспециализированный инструмент. Его стоит рассматривать только для рабочих нагрузок, которые на 100% состоят из запросов на точное совпадение (=) по уникальным или почти уникальным столбцам, и после тщательного тестирования в конкретной СУБД.