Порядок имеет значение?
Итак, теперь наши запросы выполняются быстро. Но как мы можем получить их еще быстрее?
Итак, переходя от нашего примера выше, мы хотим знать только, какие модели находятся в таблице. Используя полиморфную связь, у нас есть два столбца. 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 под капотом может переупорядочивать точные совпадения, чтобы улучшить сопоставление индексов.
Я расскажу об этом подробнее в следующей статье, посвященной анализатору плана запроса, а также о том, как определить, какие индексы будут использоваться или какие из них будут наиболее эффективными.
Обсудить можно гораздо больше, чем то, что написано в этом посте. Поэтому я начал разбивать их на отдельные записи. На данный момент я считаю, что в моем следующем посте будут обсуждаться некоторые пограничные случаи и некоторые более сложные запросы в отношении
- Типы индексов
- Что происходит при заказе за несколькими столами.
- Что происходит с лайками «а%»
- Что происходит с подзапросами и группировкой.