|
Задавайте вопросы, мы ответим
Вы не зашли.
https://mariadb.com/kb/en/limit-rows-examined/
В MariaDB 5.5.21 ввели расширение синтаксиса LIMIT:
LIMIT [[offset,] row_count] ROWS EXAMINED rows_limit;
Сервер считает кол-во прочитанных, добавленных, измененных и удаленных строк во время выполнения запроса (учитывается работа с временными таблицами на промежуточных этапах). Как только счетчик достигает значения rows_limit выполнение запроса завершается как можно скорее.
В результате запрос может вернуть пустой результат или промежуточный, например без группировки или сортировки. А один и тот же запрос с джойном в зависимости от выбранной стратегии объединения может дать разный результат.
Вопрос: каково практическое применение этой оптимизации?
Если не хочется выполнять тяжелый запрос, то логично на этапе разбора оценить его сложность и послать. А так запрос работал, работал и выдал ни мышонка, ни лягушку, а неведому зверушку.
Неактивен
Он генерирует Warning, поэтому становится понятно, что запрос не завершился. Я так понял, что сделано для экономии времени. Совершенно неканонично перед каждым запросом проверять будет он долгим или нет - ясно, что так делать никто не будет. А тут механизм, который ограничивает сложность выполняемых запросов - можно сделать сайт, на котором в 99% случаев не будет работать поиск. Поиск будет работать только если заданный запрос удобен для поиска при существующих индексах, а иначе выдаст не все результаты (а вообще непонятно сколько). Как применение: можно таким образом ограничивать возможности поиска для анонимов, например.
Неактивен
rgbeast написал:
Я так понял, что сделано для экономии времени. Совершенно неканонично перед каждым запросом проверять будет он долгим или нет - ясно, что так делать никто не будет.
По сути это и так делается на этапе составления плана выполнения, когда считается стоимость того или иного плана: оценочное число прочитанных строк из таблиц, коэффициенты на различные операции типа группировок, сортировок, объединений. Просто стоимость считается в абстрактных величинах, но ничто не мешает посчитать ещё одну формулу для оценки числа строк после того как выбран план и только для тех запросов где указан ROWS EXAMINED.
rgbeast написал:
А тут механизм, который ограничивает сложность выполняемых запросов - можно сделать сайт, на котором в 99% случаев не будет работать поиск. Поиск будет работать только если заданный запрос удобен для поиска при существующих индексах, а иначе выдаст не все результаты (а вообще непонятно сколько). Как применение: можно таким образом ограничивать возможности поиска для анонимов, например.
Нехорошо проводить дискриминацию по цвету ника. Тогда уж лучше запретить анонимам пользоваться поиском.
Пришел юзер, ткнулся в поиск, ничего не нашел и, решив, что сайт унылое г, ушел. Если с него потребовать регистрацию, он тоже уйдет, но если ничего не найдет, то вернется и зарегится.
Придумал способ использования.
На сайте сложная форма поиска, например, каталог авто-запчастей с кучей параметров. С ростом базы/посещаемости сайт начинает тормозить и тогда админ вместо того, чтобы заказать оптимизацию производительности, подкручивает параметр ROWS EXAMINED в скриптах 
Всё работает быстро, а проблемы юзеров, админа не волнуют.
Неактивен
vasya написал:
На сайте сложная форма поиска, например, каталог авто-запчастей с кучей параметров. С ростом базы/посещаемости сайт начинает тормозить и тогда админ вместо того, чтобы заказать оптимизацию производительности, подкручивает параметр ROWS EXAMINED в скриптах
Всё работает быстро, а проблемы юзеров, админа не волнуют.
Я примерно это и имел в виду - выбирайте запчасти с точки зрения оптимальности запросов MySQL. Но сразу же пришло в голову, что для админа и для платных подписчиков таких ограничений не будет. Унылость сайта будет очевидна всем, кто не может указать достаточно специфичный запрос, чтобы он быстро выполнялся.
Неактивен
Кстати, есть max_join_size, который как раз и посылает на этапе составления плана. Вот только неясно с чем именно он производит сравнение. Я полагал, что с предполагаемым количеством строк из столбца rows в explain, но
Неактивен
Не совсем уловил разницу между лимитами... стандартный лимит ограничивает количество записей уже после того как всё соединено, выбрано и отсортировано. А этот когда? Когда выбирается/соединяется?
Неактивен
А этот считает кол-во обработанных строк в процессе выполнения: прочитали из таблицы х строк; записали их во временную таблицу - значение счетчика стало 2х. Стали делать группировку методом файлсорт - стало 2х+у. И тут достигнут предел и выполнение запроса завершилось. А ведь в запросе могла быть ещё и сортировка, которая соответственно не выполнилась.
Неактивен
Вооот, собственно из-за сортировки у меня возник тот вопрос))) Это наверн актуально для результатов поиска, нашли Х результатов, зачем ещё остальные искать, если всё равно на странице только Х отображается))
Неактивен
Не, запрос может прерваться и раньше на этапе джойна, например, и выдать пустой результат.
Неактивен
Хм, т.е. если у меня в запросе джоин Х таблиц, то запрос прервётся при нахождении этого лимита записей в любой из них?
Неактивен
Нет, он может не успеть ничего найти
Это ограничение не количества выбранных таблиц, а кол-ва прочитанных, добавленных, измененных и удаленных строк во время выполнения запроса.
Неактивен
О, слово "прочитанных" всё расставило на свои места, чё-то не обратил на него внимание в первом посте))) А как быть с остальными? Ведь обычный лимит тоже ограничивает количество добавленных, измененных и удаленных... В чём разница в данном случае? Допустим, при изменении и удалении есть условия, для этого "прочитываются" записи, вроде понятно)) А при добавлении какое поведение?
Неактивен
Кажися и тут понимаю... строки временных таблиц тоже считаются?))
Неактивен
Neval написал:
Кажися и тут понимаю... строки временных таблиц тоже считаются?))
Да
Неактивен
