Порядок имеет значение?

Итак, теперь наши запросы выполняются быстро. Но как мы можем получить их еще быстрее?

Итак, переходя от нашего примера выше, мы хотим знать только, какие модели находятся в таблице. Используя полиморфную связь, у нас есть два столбца. loggableid и имя таблицы (loggableitem).

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

Мы также увеличили количество возвращаемых результатов, чтобы лучше показать разницу в индексах.

Итак, с нашим новым запросом:

  • Запуск без нашего индекса tablename занимает 38 секунд.
  • Работа с нашим индексом tablename занимает 37 секунд.

Теперь мы можем пойти дальше и сделать больше с этим.

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

(Упрощенное представление того, как показывает индекс, внутри все по-другому)

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

Если мы также добавим наш loggableid в индекс, наш индекс может быть представлен следующим образом:

Это занимает в среднем всего 4,1 секунды, примерно в 16 раз быстрее, чем наш другой запрос.

Теперь, если у нас еще не было индекса имени таблицы, и вы собирались добавить оба столбца. В каком порядке вы бы расположили его?

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

Почему это? Ну, если мы визуализируем индекс (loggableid, tablename), мы получим следующее:

Итак, учитывая наши две визуализации, какая из них будет быстрее, чтобы вы сказали мне, в каком порядке они появляются в зависимости от имени таблицы?

Итак, что мы можем извлечь из этого?

  • Порядок индексов имеет значение.
  • Индексы, которые «упорядочены по», должны иметь приоритет над неупорядоченными индексами.
  • Работаем слева направо по индексу (исключая кортеж /id )

Если порядок индексов имеет значение при сортировке, как насчет множественных адресов?

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

Давайте найдем все остальные, у которых регистрируемый идентификатор меньше 40 миллионов. (Это уменьшает наш набор данных, но сохраняет более 2 миллионов результатов.)

В настоящее время: Запуск без индексов (кроме первичного ключа): 40 секунд Запуск с индексом tablename: 40 секунд Запуск с loggable, tablename index: 40 секунд Запуск с tablename, loggable index: 40 секунд

Итак, что здесь происходит? Как и выше с упорядочением индекса с сортировкой. Порядок расположения предложений where влияет на то, какой индекс можно использовать. Если бы мы изменили порядок адресов, чтобы сначала использовать имя таблицы, а затем регистрируемый идентификатор:

Наш запрос снова сокращается до 4 секунд.

Если порядок, в котором мы добавляем наши «где», влияет на то, какой индекс можно использовать. Итак, когда порядок не имеет значения?

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

Я расскажу об этом подробнее в следующей статье, посвященной анализатору плана запроса, а также о том, как определить, какие индексы будут использоваться или какие из них будут наиболее эффективными.

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

  • Типы индексов
  • Что происходит при заказе за несколькими столами.
  • Что происходит с лайками «а%»
  • Что происходит с подзапросами и группировкой.