Индексирование логических полей

Question

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

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

Answer 1

номер

Вы индексируете поля, в которых выполняется поиск и которые имеют высокую селективность / количество элементов. Кардинальность логического поля стирается практически на любом столе. Во всяком случае, это сделает ваши записи медленнее (на очень маленькую величину).

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

Answer 2

А как насчет столбца DATETIME исключено_ в? Есть два преимущества.

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

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

SELECT * FROM xyz WHERE deleted_at IS NULL

Answer 3

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

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

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

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

Answer 4

Я думаю, что если ваше логическое поле таково, что вы будете ссылаться на него во многих случаях, имеет смысл иметь отдельную таблицу, например DeletedPages или SpecialPages, которая будет иметь много полей логического типа, например 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, чтобы индексирование работало в этом поле, но, пожалуйста, подтвердите это.

Answer 5

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

Answer 6

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