Оптимизация вложенных запросов
Вложенные запросы (подзапросы) могут использовать оператор SELECT для создания результата запроса с одним столбцом, который затем можно использовать в качестве условия фильтра в другом запросе. Вложенные запросы просты в написании и понятны. Однако иногда его можно заменить более эффективным объединением (JOIN).
Теперь, если вы хотите найти клиентов, которые никогда не совершали покупок на веб-сайте, то есть запросить информацию о клиенте в таблице клиентов, а не в таблице платежей.
Вложенный запрос:
explain select * from customer where customer_id not in (select customer_id from payment);
Перезапись соединения:
explain select * from customer a left join payment b on a.customer_id = b.customer_id where b.customer_id is null;
Голос за кадром: Причина, по которой запросы на соединение более эффективны, заключается в использовании MySQL.Нет необходимости создавать временные таблицы в памятидля завершения этого логически двухэтапного запроса; иNot existsУказывает, что MYSQL оптимизирует LEFT JOIN, и как только он находит строку, соответствующую критериям LEFT JOIN, он больше не выполняет поиск.
Оптимизация запросов на разбивку на страницы
При выполнении запроса на подкачку в MySQL MySQL не пропускает строки смещения, а выбирает строки смещения + N, а затем возвращается, чтобы отбросить предыдущие строки смещения и возвращает строки N. Когда смещение особенно велико, эффективность очень низкая. Например, «ограничить 1000,20», в настоящее время MySQL нужны только записи с 1001-й по 1020-ю после сортировки первых 1020 фрагментов данных, и первые 1000 фрагментов данных будут отброшены, а стоимость запроса и сортировки очень высока. высокий. Видно, что обработка подкачки MySQL не идеальна, и нам нужно выполнить некоторую оптимизацию SQL подкачки, илиКонтролирует общее количество возвращаемых страницили даКоличество страниц сверх определенного порога для перезаписи SQL.
Голос за кадром: Контроль общего количества возвращаемых страниц не так надежен, ведь количество данных на странице не может быть слишком большим, после увеличения данных становится нереально контролировать общее количество возвращаемых страниц. Так ещеПерезапись SQL для страниц, которые превышают определенный порог.
Теперь предположим, что вы хотите получить определенную страницу данных после сортировки таблицы фильмов.
explain select * from film order by title limit 50,5;
Видно, что оптимизатор действительно выполняет полное сканирование таблицы, и эффективность обработки невысока.
Первая идея оптимизации
Завершите операцию сортировки и разбиения по страницам в индексе и, наконец, свяжите его с другим содержимым столбца, требуемым запросом таблицы, в соответствии с первичным ключом.
Голос за кадром: Здесь задействованы две важные концепции оптимизации SQL.Покрытие индекса и сводная таблица, я подробно рассмотрел обе концепции в предыдущей статье. Сканирование и сортировка выполняются в индексе посредством покрытия индекса (индекс упорядочен), и, наконец, первичный ключ (индекс механизма InnoDB будет возвращаться к таблице через первичный ключ) используется для запроса таблицы, сводя к минимуму количество операций ввода-вывода. для запроса обратно к таблице.
explain select * from film a inner join (select film_id from film order by title limit 50,5)b on a.film_id = b.film_id;
Вторая идея оптимизации
Преобразуйте запрос LIMIT в запрос в определенном месте, чтобы уменьшить нагрузку на пейджинг.
Предположим теперь, что на странице 10 штук данных, нужно взять данные на 42-й странице.
explain select * from film order by title limit 410,10;
Теперь вам нужно передать еще один параметр, который является названием темы последнего фрагмента данных на предыдущей странице (страница 41).
SQL можно переписать как:
explain select * from film where title>'HOLES BRANNIGAN' order by title limit 10;
Это преобразует LIMIT m,n в запрос LIMIT n, но эта схема подходит только для конкретных сред, где не встречаются повторяющиеся значения, иначе результаты пейджинга могут потерять данные.
Суммировать
Для оптимизации вложенных запросов и запросов на подкачку, в конечном счете, необходимо следовать одному из принципов оптимизации SQL — уменьшению количества операций ввода-вывода для запросов обратно к таблице. Для оптимизации запросов на подкачку рекомендуется использовать первую схему оптимизации, которая имеет лучшую производительность и более высокую стабильность.
Ссылаться на
«Углубленный MySQL»