Использование столбцов boolean или enum в индексах?

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

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

Значит, было бы неплохо поставить индекс на такой столбец?

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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