Виноград
описывать
Сегодня я обнаружил несколько медленных запросов при запуске сценария. Согласно моему предыдущему опыту, мне действительно не следовало этого делать. После поиска данных и анализа результатов я просто запишу их здесь.
Во-первых, мой SQL выглядит так:
select `id` from `xxx` force index(idx_d_t) where `date` = '2019-09-11' AND `time_flag` < '20190911220000' order by id asc;
Индекс выглядит следующим образом ниже:
KEY `inx_t_d` (`date`,`time_flag`);
Согласно моему предыдущему пониманию, этот SQL может перейти к этому индексу, но это не так. Он выбрал индекс первичного ключа.
анализ
Видя, что это медленный запрос, я начал объяснение, и результаты следующие:
Увидев этот результат, я уверен, что не приму ах, почему индекс первичного ключа, так началось путешествие Baidu в Google. В самом начале я нашел относительно правильный метод. Я нашел статью в определенной степени, в которой говорилось, что если бы до orderby был поиск по диапазону, он следовал бы за индексом после orderby. Наоборот, я попробовал это сделать. Ах, да, я изменил запрос диапазона на эквивалентный запрос и оставил свой индекс. Но я посмотрел на количество строк и пришел в замешательство. Почему это так много? Это не то, чего я хочу
Затем я проверил время и обнаружил, что создание индекса сортировки занимало 90% времени. В это время я остро осознавал, что с такого рода сортировкой возникла проблема, (пришло время поесть) нет, продолжайте проверять! Продолжайте проверять, на брате, ах, не говорите, брат Дафа все еще хорош, наконец-то нашел анализ большого человека, в чем конкретная причина?
Впервые я заставил свой индекс профсоюзов посмотреть на следующее:
Если вы посмотрите на картинку выше, вы обнаружите, что есть разница между использованием файловой системы. Что это за штука? Проще говоря, сортировка файлов заключается в сортировке полученных данных в памяти с помощью соответствующего алгоритма сортировки. Как говорится, вред есть только тогда, когда есть контраст. Если мы поймаем врага за косичку, мы будем близки к победе. Давайте продолжим смотреть.
Сортировку файлов можно выполнить двумя способами:
- Двусторонняя сортировка: сначала соответствующие поля сортировки и информация указателя строки, которые могут непосредственно находить данные строки, извлекаются в соответствии с соответствующими условиями, а затем сортировка выполняется в буфере сортировки.
- Сортировка по одному пути: все поля строки, соответствующие условиям, извлекаются одновременно, а затем сортируются в буфере сортировки.
Когда вы используете эти два? MySQL в основном сравнивает установленный системный параметр max_ length_ для_ сортировки.Сумма размера данных и размера типа поля, полученного с помощью инструкции запроса, определяет, какой алгоритм сортировки использовать. Если Max_ длина для_ сортировки, если данные больше, используется второй оптимизированный алгоритм, в противном случае используется первый алгоритм. Очевидно, что MySQL должен выбрать использование второго одностороннего алгоритма для максимально возможной сортировки. Это может сократить большое количество случайных операций ввода-вывода и значительно повысить эффективность работы по сортировке.
Время сортировки приведенного выше анализа слишком велико, что может быть связано с этим. Если мы продолжим проверять данные и анализировать их, то ключ к проблеме заключается в том, почему используется сортировка файлов.
заключение
При выполнении инструкции из-за большого объема данных оптимизатор MySQL считает, что использовать федеративный индекс нецелесообразно, и по умолчанию выбирает первый более медленный план выполнения. Причина в том, что индекс первичного ключа не нуждается в сортировке памяти, и идентификатор кандидата выбран_ D_ T был удален. Оптимизатор считает, что индекс первичного ключа лучше, чем объединенный индекс без сортировки, что приводит к такой ситуации, Что нам делать? Здесь я только перечисляю свои решения. Он думает, что первичный ключ лучше, поэтому мы дадим ему лучший. Мы можем изменить IDX_ D_ T этот индекс определяется датой, временем, флагом изменения на идентификатор, дату, флаг времени, что решает проблему. Как показано на рисунке:
В заключение оптимизатор попытается избежать сортировки файлов, что может вызвать некоторые проблемы.
Если в приведенном выше анализе есть какая-либо ошибка, пожалуйста, дайте мне свой совет! благодарить.
Справочные статьи:
- Неправильный индекс порядка MySQL по лимиту