Индексирование булевых полей

Это, наверное, действительно глупый вопрос, но будет ли большая польза в индексировании булевского поля в таблице базы данных?

Учитывая общую ситуацию, например записи "soft-delete", которые помечены как неактивные, и, следовательно, большинство запросов включают WHERE deleted = 0, поможет ли это индексировать это поле самостоятельно или же оно должно быть объединено с другим обычно просматриваемые поля в другом индексе?

Ответ 1

Нет.

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

Может быть, вы сделали бы это первое поле в кластерном индексе, если бы каждый запрос учитывал мягкое удаление?

Ответ 2

Что такое столбец deleted_at DATETIME? Есть два преимущества.

Если вам нужен уникальный столбец, такой как имя, вы можете создавать и мягко удалять запись с тем же именем несколько раз (если вы используете уникальный индекс для столбцов deleted_at AND name)
Вы можете искать недавно удаленные записи.

Запрос может выглядеть так:

SELECT * FROM xyz WHERE deleted_at IS NULL

Ответ 3

Я думаю, что это помогло бы, особенно при освещении индексов.

Сколько/немного зависит от ваших данных и запросов.

У вас могут быть теории всех видов индексов, но окончательные ответы даны механизмом базы данных в базе данных с реальными данными. И часто вас удивляет ответ (или, может быть, мои теории слишком плохи;)

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

Ответ 4

Я думаю, что если ваше логическое поле таково, что вы будете ссылаться на них во многих случаях, имеет смысл иметь отдельную таблицу, например, DeletedPages или SpecialPages, которая будет иметь много полей типа boolean, например is_deleted, is_hidden, is_really_deleted, requires_higher_user и т.д., а затем вы получите соединения для их получения.

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

select all pages where is_deleted = 1

Было бы быстрее реализовать его следующим образом:

select all pages where pages 
inner join DeletedPages on page.id=deleted_pages.page_id

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

Ответ 5

Я думаю, что это поможет, если вы используете представление (где deleted = 0), и вы регулярно запрашиваете его из этого представления.

Ответ 6

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