Очень странное поведение MYSQL c LIMIT?

Question

[GeKskill]

Добрый день.
Обнаружил очень интересную особенность в скорости выполнения запроса с LIMIT на крайних значениях, сейчас все покажу.
1) Выполнение запроса без лимита - в среднем 0.3с

2) Выполнение запроса с лимитом на 1 больше, чем заранее известное кол-во результатов - в среднем 0.3с

3) Выполнение запроса с лимитом равным заранее известному кол-ву результатов - в среднем 0.08 ( на 350% быстрее )

4) Выполнение запроса с лимитом равным заранее известному кол-ву результатов минус 20% - в среднем 0.04 ( на 750% быстрее )

5) И далее при уменьшении лимита скорость ответа растет, вплоть до 0.005с.

В профилировании все время у 1 и 2 варианта занимает Executing (понять что за этим скрывается).
Какой механизм обработки запроса с лимитом так сильно ускоряет процесс и как использовать эту фишку себе на пользу?

Comments

[Дмитрий]

А вы эти запросы с отключенным кешом MySQL делали?

[GeKskill]

Дмитрий, MySQL версии 8 без кэша запросов уже идет. Но в качестве подстраховки проверил ещё раз, добавив SQL_NO_CACHE к запросу, результаты аналогичные

[Дмитрий]

GeKskill, в 8 по-моему отключили SQL_NO_CACHE, не?

В 8 вроде как через query_cache_size

[Rsa97]

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

[Akina]

А если ещё и WHERE IN заменить на соответствующие INNER JOIN...

[nokimaro]

У вас в phpmyadmin там есть галочка "Профилирование" которую можно нажать и получить подробности того на что тратится время и где тормоза
Банально могут влиять размеры буфферов в настройке. Но как правильно чем больше данных - тем дольше ждать.

[Дмитрий]

GeKskill, ан, нет. совсем от мускула похоже отстал

[GeKskill]

nokimaro, я делал его, там все уходит на Executing без подробностей о процессах

[GeKskill]

Akina, пробовал через join, разницы не увидел, но это ещё когда без лимитов тестировал, может с ним ещё быстрее летает

[GeKskill]

Rsa97, тогда бы этот кэш срабатывал бы и для запроса без лимита - тот, что под номером 1. Тут дело скорее в обработке запроса подсистемой самой mysql, возможно при лимите какие-то проверки отключаются

[Rsa97]

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

[GeKskill]

Rsa97, это понятно, так я и писал, что при повторном запросе №1 кэш ( если бы дело было в нем ) тоже отрабатывал бы и показывал чуть ли не 0.00004с, но это не так, хоть 10-20 раз обновляй запрос, время остается тоже самое. Значит кэш не используется в принципе.

[smilingcheater]

GeKskill, EXPLAIN запроса смотрели? Теоретически, если таблицы большие, но все нужные результаты находятся в начале - то mysql просто находит в начале все нужные 292 строки и не смотрит таблицы до конца. Если же ставить лимит 293 - приходится просматривать таблицы полностью.

[GeKskill]

smilingcheater, explain у них идентичный

" все нужные результаты находятся в начале" - как он это поймет не досмотрев до конца?)

[Akina]

GeKskill,

" все нужные результаты находятся в начале" - как он это поймет не досмотрев до конца?)

Элементарно. В ваших запросах вообще отсутствует сортировка. А потому сервер волен вернуть любые записи. А он не идиот, и потому вернёт первые из подвернувшихся.
Да и вообще LIMIT без уникальной сортировки - это забава для любителей лотереи.

[GeKskill]

Akina, а вот похоже и ответ... Только что добавил к запросам с лимитом сортировку и сразу стало отдавать за 0.3с как и в базовом запросе.

[Руслан .]

GeKskill, а это странно. У вас в запросах есть distinct. А значит под капотом есть и сортировка.