Какое минимальное количество строк, где индексирование становится полезным в MySQL?

Question

Я читал, что индексирование в некоторых базах данных (SQL Сервер - это тот, о котором я читал ) не имеет большого эффекта, пока вы не пересечете определенный порог строк, потому что база данных будет содержать вся таблица X в памяти.

Обычно я планирую индексировать свои WHERE и уникальные столбцы / менее измененные таблицы. Услышав о предлагаемом минимуме (, который составлял около 10k ), я захотел узнать больше об этой идее. Если есть таблицы, которые, как я знаю, никогда не пройдут определенную точку, это может изменить способ индексации некоторых из них.

Для чего-то вроде MySQL MyISAM / INNODB, существует ли точка, в которой индексирование имеет небольшое значение и каковы некоторые способы определения этого?

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

Answer 1

Одним из основных применений индексов является уменьшение количества читаемых страниц. Сам индекс обычно меньше таблицы. Таким образом, только с точки зрения чтения / записи страницы , вам, как правило, нужно по крайней мере три страницы данных, чтобы увидеть преимущество, потому что для использования индекса требуется как минимум две страницы данных (одна для индекса и одна для оригинала data).

(На самом деле, если индекс охватывает запрос, то безубыточность равна двум.)

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

Приведенное выше очень элементарное объяснение оставляет несколько вещей:

• Стоимость сканирования страниц данных проводить сравнения для каждой строки.
• Стоимость загрузки и использования страниц индекса.
• Другие виды использования индексации.

Но это дает вам представление, и Вы можете увидеть преимущества таблиц, которые меньше, чем 10 000 строк. Тем не менее, вы можете легко выполнить тестирование ваших данных, чтобы увидеть, как запросы работают с соответствующими таблицами.

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

Answer 2

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

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

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

Но даже при извлечении больших подмножеств соответствующие индексы могут повысить производительность операций объединения и значительно повысить производительность запросы с предложениями GROUP BY или ORDER BY, используя индекс для извлечения строк по порядку, а не требуя операции «Использование файловой сортировки».

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

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

С точки зрения понимания, используйте EXPLAIN, чтобы увидеть план выполнения. Изучите операции, доступные оптимизатору MySQl.

(Топика c стратегии индексации с точки зрения производительности базы данных слишком велика для вопроса StackOverflow.)

Answer 3

Каждая ситуация отличается. Если вы профилируете свой код, то вы будете лучше понимать каждый анти-паттерн. Чтобы продемонстрировать крайнюю неожиданность, рассмотрим Oracle:

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

Тот же процесс, который я прошел, чтобы понять Oracle, вы можете сделать с MySQL: профилировать ваш код.