8.2.1.3. Оптимизация `LIMIT` Запросы

Если Вы нуждаетесь в только конкретном количестве строк от набора результатов, используйте a LIMIT пункт в запросе, вместо того, чтобы выбрать целый набор результатов и выбросить дополнительные данные.

MySQL иногда оптимизирует запрос, у которого есть a LIMIT row_count пункт и нет HAVING пункт:

Если Вы выбираете только несколько строк с LIMIT, Использование MySQL индексирует в некоторых случаях, когда обычно это предпочло бы делать полное сканирование таблицы.
Если Вы используете LIMIT row_count с ORDER BY, MySQL заканчивает сортировку, как только это нашло первое row_count строки сортированного результата, вместо того, чтобы сортировать весь результат. Если упорядочивание делается при использовании индексирования, это очень быстро. Если filesort должен быть сделан, все строки, которые соответствуют запрос без LIMIT пункт выбирается, и больше всего или все они сортируются перед первым row_count находятся. После того, как начальные строки были найдены, MySQL не сортирует остатка от набора результатов.
Объединяясь LIMIT row_count с DISTINCT, MySQL останавливается, как только он находит row_count уникальные строки.
В некоторых случаях, a GROUP BY может быть разрешен, читая ключ в порядке (или делая вид на ключе) и затем вычисляя сводки до изменений значения ключа. В этом случае, LIMIT row_count не вычисляет никого ненужного GROUP BY значения.
Как только MySQL отправил необходимое число строк клиенту, это прерывает запрос, если Вы не используете SQL_CALC_FOUND_ROWS.
LIMIT 0 быстро возвращает пустое множество. Это может быть полезно для проверки законности запроса. При использовании одного из API MySQL это может также использоваться для того, чтобы получить типы столбцов результата. (Этот прием не работает в MySQL Monitor (mysql программа), который просто выводит на экран Empty set в таких случаях; вместо этого, используйте SHOW COLUMNS или DESCRIBE с этой целью.)
Когда сервер использует временные таблицы, чтобы разрешить запрос, он использует LIMIT row_count пункт, чтобы вычислить, сколько пространства требуется.

Оптимизатор действительно обрабатывает запросы (и подзапросы) следующей формы:

SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

Тот тип запроса распространен в веб-приложениях, которые выводят на экран только несколько строк от большего набора результатов. Например:

SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

У буфера вида есть размер sort_buffer_size. Если элементы вида для N строки являются достаточно небольшими, чтобы поместиться в буфер вида (M+N строки, если M был определен), сервер может избегать использования файла слияния и выполнить вид полностью в памяти, обрабатывая буфер вида как приоритетная очередь:

Отсканируйте таблицу, вставляя столбцы списка выборки от каждой выбранной строки в сортированном порядке в очереди. Если очередь полна, удар последняя строка в порядке сортировки.
Возвратите первое N строки от очереди. (Если M был определен, пропустите первое M строки и возврат следующее N строки.)

Ранее, сервер, выполняемый эта работа при использовании файла слияния для вида:

Отсканируйте таблицу, повторяя эти шаги через конец таблицы:
- Выберите строки, пока буфер вида не заполнен.
- Запишите первое N строки в буфере (M+N строки, если M был определен) к файлу слияния.
Сортируйте файл слияния и возвратите первое N строки. (Если M был определен, пропустите первое M строки и возврат следующее N строки.)

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

Метод очереди включает больше ЦП для того, чтобы вставить строки в очередь в порядке
У метода файла слияния есть затраты ввода-вывода со стороны записи, и считайте файл и стоимость ЦП, чтобы сортировать это

Оптимизатор рассматривает баланс между этими факторами для определенных значений N и размер строки.

8.2.1.3. Оптимизация LIMIT Запросы

8.2.1.3. Оптимизация `LIMIT` Запросы