Я собираюсь написать запрос, содержащий WHERE isok=1. Как следует из названия, isok - это логическое поле (фактически a TINYINT(1) UNSIGNED, которое установлено на 0 или 1 по мере необходимости).
Есть ли какой-либо прирост производительности при индексировании этого поля? Может ли двигатель (InnoDB в этом случае) лучше или хуже искать индекс?
Не совсем. Вы должны думать об этом как о книге. Если в книге было всего 3 вида слов, и вы индексировали их все, у вас было бы такое же число индексных страниц, что и обычные страницы.
Было бы увеличение производительности, если относительно немного записей одного значения. Например, если у вас 1000 записей и 10 из них имеют значение ИСТИНА, тогда было бы полезно, если вы выполните поиск с помощью isok = 1
Как упоминал Майкл Даррант, он также делает записи медленнее.
EDIT: Возможное дублирование: Индексирование логических полей
Здесь объясняется, что даже если у вас есть индекс, если у вас слишком много записей, он все равно не использует индекс. MySQL не использует индекс при проверке = 1, но используя его с = 0
Как раз для того, чтобы рассказать о нескольких других ответах здесь, поскольку, по моему опыту, те, кто смотрит на такие вопросы, находятся в той же лодке, что и мы, мы все слышали, что индексирование булевых полей бессмысленно и все же...
У нас есть таблица с примерно 4 миллионами строк, только около 1000 или около того за один раз будет иметь флаг Boolean, который помечен, и то, что мы ищем. Добавление индекса в нашем булевом поле ускоряло запросы на порядки, оно составляло от 9 + секунд до доли секунды.
Это зависит от фактических запросов и селективности комбинации индекса/запроса.
Случай 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) будет еще лучше.
Нет, обычно нет.
Обычно вы индексируете поля для поиска, когда они имеют высокую избирательность/мощность. В большинстве таблиц мощность булевого поля очень низкая. Это также сделает ваши записи менее медленными.
Да, индекс повысит производительность, проверьте вывод EXPLAIN с индексом и без него.
Из документов:
Индексы используются для быстрого поиска строк с конкретными значениями столбцов. Без индекса MySQL должен начинаться с первой строки, а затем читать всю таблицу, чтобы найти соответствующие строки. Чем больше стол, тем больше это стоит. Если таблица имеет индекс для рассматриваемых столбцов, MySQL может быстро определить позицию для поиска в середине файла данных без необходимости просмотра всех данных.
Я думаю, что также безопасно сказать, что индекс не уменьшит производительность в этом случае, поэтому вам нужно только выиграть от него.
На самом деле это зависит от запросов, которые вы запускаете. Но, как правило, да, а также индексирование поля любого другого типа.
Это зависит от распределения данных.
Представьте, что у меня была книга с 1000 тесно напечатанными страницами, и единственные слова в моей книге были "да" и "нет" повторялись снова и снова и распределялись случайным образом. Если бы меня попросили объединить все случаи "да" , поможет ли индекс в задней части книги? Это зависит.
Если бы было полутора с половиной случайного распределения да и нет, то поиск индекса не помог бы. Индекс сделает книгу намного больше, и в любом случае я буду быстрее, чтобы начать с фронта и прокладывать себе путь по каждой странице, ища все примеры "да" и кружить их, вместо того, чтобы искать каждый элемент в указатель, а затем ссылается на ссылку с позиции индекса на страницу, на которую он ссылается.
Но если бы в моей книжке на тысячу страниц было всего десять экземпляров "да" , а все остальное было всего лишь миллионами нулей, то индекс спасет меня от времени, найдя эти десять экземпляров "да" , и кружить их.
То же самое в базах данных. Если это распределение 50:50, то индекс не поможет - движок базы данных лучше просто вспахивать данные от начала до конца (полное сканирование таблицы), и индекс просто сделает базу данных больше, и медленнее писать и обновлять. Но если это что-то вроде дистрибутива 4000: 1 (как в oucil в этом потоке), тогда поиск индекса может ускорить его, если это 1 из 4000 предметов, которые вы ищете.