Использование логических или перечислимых столбцов в индексах?

Question

Я читал, что столбцы, выбранные для индексов, должны хорошо различать строки, то есть столбцы индекса не должны содержать большое количество строк с одинаковым значением. Это предполагает, что логическое значение или перечисление, такое как пол, будет плохим выбором для индекса.

Но, скажем, я хочу найти пользователей по полу и в моей конкретной базе данных только 2% пользователей составляют женщины, тогда в этом случае кажется, что столбец пола будет полезным индексом при получении пользователей женского пола, но не при получении всех пользователей мужского пола.

Так будет ли хорошей идеей поместить индекс в такой столбец?

Answer 1

Индексирование столбца с минимальным количеством элементов для повышения эффективности поиска является обычным явлением в моем мире. Oracle поддерживает «растровый индекс», который разработан для этих ситуаций. См. эту статью для краткого обзора.

Большая часть моего опыта связана с Oracle, но я предполагаю, что другие СУБД поддерживают нечто подобное.

Answer 2

Не забывайте, однако, что вы, вероятно, будете выбирать для женщин только около 2% времени. В остальное время вы будете искать мужчин. И для этого прямое сканирование таблицы (а не сканирование индекса плюс доступ к данным из таблицы) будет быстрее.

Вы также можете иногда использовать составной индекс со столбцом низкой мощности (enum, boolean) в сочетании со столбцом более высокой мощности (возможно, дата рождения). Это очень сильно зависит от полных данных и запросов, которые вы действительно будете использовать.

Мой опыт показывает, что индекс по мужчинам / женщинам редко будет действительно полезным. И общий совет действителен. Еще один момент, который нужно помнить - индексы должны поддерживаться при добавлении или удалении (или обновлении) строк. Чем больше индексов, тем больше работы должна выполнять каждая операция модификации, замедляя работу системы.

Есть целые книги по дизайну указателей.

Answer 3

Это тот случай, когда я позволяю статистике сервера сообщать мне, когда создавать индекс. Если вы не знаете, что этот запрос будет преобладать или что выполнение такого запроса априори не будет соответствовать вашим целям производительности, то преждевременное создание индекса может просто повысить производительность, а не повысить ее. Кроме того, вы можете подумать о том, как вы на самом деле будете использовать запрос. В этом случае, я предполагаю, что вы, скорее всего, будете выполнять агрегацию на основе этого столбца, а не просто выбирать пользователей, которые соответствуют критериям. В этом случае вы все равно будете выполнять сканирование таблицы, и индекс ничего не купит.