Почему нельзя использовать Hash-индекс везде в базах данных

Hash-индексы оптимальны только для операций точного совпадения (=), но имеют серьёзные ограничения:

Ограничения Hash-индексов:

1. Не поддерживают диапазонные запросы

   -- Hash-индекс НЕ поможет
   SELECT * FROM orders WHERE total_amount > 1000;
   SELECT * FROM users WHERE created_at BETWEEN '2023-01-01' AND '2023-12-31';

2. Не поддерживают сортировку (ORDER BY)

   -- Неэффективно с Hash-индексом
   SELECT * FROM products ORDER BY price DESC;

3. Не поддерживают поиск по префиксу

   -- Hash-индекс бесполезен
   SELECT * FROM articles WHERE title LIKE 'PHP%';

4. Только операции равенства — Hash-индекс вычисляет хэш-значение, поэтому WHERE id = 5 работает быстро, но WHERE id > 5 — нет.

Практический пример из PostgreSQL:

-- Создаём Hash-индекс для точного поиска по email
CREATE INDEX idx_users_email_hash ON users USING hash(email);

-- Эффективный запрос
SELECT * FROM users WHERE email = 'alice@example.com';

-- Для этих запросов нужен B-tree индекс
CREATE INDEX idx_users_created_btree ON users(created_at);
SELECT * FROM users WHERE created_at > '2024-01-01' ORDER BY created_at;

Когда использовать Hash-индекс:

• Таблицы поиска (lookup tables) с уникальными значениями
• Частые запросы с = без сортировки
• Когда данные часто обновляются (в некоторых СУБД Hash эффективнее для вставок)

В MySQL InnoDB Hash-индексы используются автоматически для адаптивного хэширования, но явно создать Hash-индекс нельзя.