Есть ли какой-либо прирост производительности при индексировании булевского поля?

Ответ 1

Не совсем. Вы должны думать об этом как о книге. Если в книге было всего 3 вида слов, и вы индексировали их все, у вас было бы такое же число индексных страниц, что и обычные страницы.

Было бы увеличение производительности, если относительно немного записей одного значения. Например, если у вас 1000 записей и 10 из них имеют значение ИСТИНА, тогда было бы полезно, если вы выполните поиск с помощью isok = 1

Как упоминал Майкл Даррант, он также делает записи медленнее.

EDIT: Возможное дублирование: Индексирование логических полей

Здесь объясняется, что даже если у вас есть индекс, если у вас слишком много записей, он все равно не использует индекс. MySQL не использует индекс при проверке = 1, но используя его с = 0

Ответ 2

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

У нас есть таблица с примерно 4 миллионами строк, только около 1000 или около того за один раз будет иметь флаг Boolean, который помечен, и то, что мы ищем. Добавление индекса в нашем булевом поле ускоряло запросы на порядки, оно составляло от 9 + секунд до доли секунды.

Ответ 3

Это зависит от фактических запросов и селективности комбинации индекса/запроса.

Случай A: условие WHERE isok = 1, и больше ничего нет:

SELECT *
FROM tableX
WHERE isok = 1

• Если индекс достаточно избирательный (например, у вас есть 1M строк и только 1k имеет isok = 1), тогда SQL-движок, вероятно, будет использовать индекс и будет быстрее, чем без него.

• Если индекс не является достаточно избирательным (скажем, у вас 1M строк и более 100k есть isok = 1), тогда SQL-движок, вероятно, не будет использовать индекс и сделает таблицу сканирования.

Случай B: условие WHERE isok = 1 и многое другое:

SELECT *
FROM tableX
WHERE isok = 1
  AND another_column = 17

Тогда это зависит от того, какие у вас другие индексы. Индекс на another_column, вероятно, будет более избирательным, чем индекс на isok, который имеет только два возможных значения. Индекс на (another_column, isok) или (isok, another_column) будет еще лучше.

Ответ 4

Нет, обычно нет.

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

Ответ 5

Да, индекс повысит производительность, проверьте вывод EXPLAIN с индексом и без него.

Из документов:

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

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

Ответ 6

На самом деле это зависит от запросов, которые вы запускаете. Но, как правило, да, а также индексирование поля любого другого типа.

Ответ 7

Это зависит от распределения данных.

Представьте, что у меня была книга с 1000 тесно напечатанными страницами, и единственные слова в моей книге были "да" и "нет" повторялись снова и снова и распределялись случайным образом. Если бы меня попросили объединить все случаи "да" , поможет ли индекс в задней части книги? Это зависит.

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

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

То же самое в базах данных. Если это распределение 50:50, то индекс не поможет - движок базы данных лучше просто вспахивать данные от начала до конца (полное сканирование таблицы), и индекс просто сделает базу данных больше, и медленнее писать и обновлять. Но если это что-то вроде дистрибутива 4000: 1 (как в oucil в этом потоке), тогда поиск индекса может ускорить его, если это 1 из 4000 предметов, которые вы ищете.