Есть ли прирост производительности при индексировании логического поля?

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

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

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

РЕДАКТИРОВАТЬ: возможное дублирование: Индексирование логических полей

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

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

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

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

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

SELECT *
FROM tableX
WHERE isok = 1

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

• Если индекс недостаточно избирательный (скажем, у вас 1 миллион строк и более 100 тысяч имеют 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) был бы даже лучше.

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

Представьте, что у меня есть книга с 1000 тщательно напечатанными страницами, и единственными словами в моей книге были «да» и «нет», повторяющиеся снова и снова и распределяемые случайным образом. Если бы меня попросили обвести все «да», поможет ли указатель в конце книги? По-разному.

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

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

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

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

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

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

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

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

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

Я также думаю, что можно с уверенностью сказать, что в этом случае производительность индекса не будет УМЕНЬШИТЬ, поэтому вам нужно только получить от этого выгоду.