В каких случаях лучше использовать хеш-индекс и почему он не всегда подходит

Что проверяют

Понимаете ли вы, что тип индекса выбирается под форму запроса. Заодно проверяют, знаете ли вы, почему хеш-индексы редко встречаются на практике.

Как отвечать

Хеш-индекс хранит не отсортированные значения, а хеш ключа, и по нему сразу попадает в нужную корзину. Отсюда сильная сторона: поиск по точному равенству за примерно постоянное время, независимо от размера таблицы. Отсюда же и слабые места.

Когда он уместен:

• запросы вида where key = ? и никаких диапазонов;
• очень длинные ключи, например ссылки или текстовые идентификаторы: хеш занимает меньше места, чем полное значение в B-дереве;
• поиск по равенству на большой таблице, где выигрыш заметен на фоне обычного индекса.

Почему подходит не всегда:

• не работает с диапазонами и сортировкой: between, >, order by и like 'x%' он не покрывает, а B-дерево покрывает;
• не поддерживает поиск по префиксу составного ключа и в PostgreSQL вообще не бывает составным;
• не обеспечивает уникальность: ограничения unique и первичный ключ строятся на B-дереве;
• чувствителен к коллизиям, а при интенсивной записи страдает от перестроения корзин.

Отдельно упомяните историю: до PostgreSQL 10 хеш-индексы не писались в журнал упреждающей записи, то есть не переживали сбой и не реплицировались, поэтому пользоваться ими не рекомендовали. Сейчас это исправлено, но привычка «по умолчанию B-дерево» осталась, и она разумна: B-дерево универсально и почти не проигрывает на равенстве.

Где спотыкаются

Считают хеш-индекс быстрее всегда. На равенстве разница обычно невелика, а на всём остальном он просто не применяется.

Забывают, что индекс нужен ещё и для сортировки с пагинацией.

Не проверяют планом, что индекс выбран: EXPLAIN покажет, использовался ли он вообще.