SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 03.01.2014 16:20:25

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

LIMIT ROWS EXAMINED

https://mariadb.com/kb/en/limit-rows-examined/

В MariaDB 5.5.21 ввели расширение синтаксиса LIMIT:

LIMIT [[offset,] row_count] ROWS EXAMINED rows_limit;

Сервер считает кол-во прочитанных, добавленных, измененных и удаленных строк во время выполнения запроса (учитывается работа с временными таблицами на промежуточных этапах). Как только счетчик достигает значения rows_limit выполнение запроса завершается как можно скорее.
В результате запрос может вернуть пустой результат или промежуточный, например без группировки или сортировки. А один и тот же запрос с джойном в зависимости от выбранной стратегии объединения может дать разный результат.

Вопрос: каково практическое применение этой оптимизации?
Если не хочется выполнять тяжелый запрос, то логично на этапе разбора оценить его сложность и послать. А так запрос работал, работал и выдал ни мышонка, ни лягушку, а неведому зверушку.

Неактивен

 

#2 03.01.2014 16:31:40

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3878

Re: LIMIT ROWS EXAMINED

Он генерирует Warning, поэтому становится понятно, что запрос не завершился. Я так понял, что сделано для экономии времени. Совершенно неканонично перед каждым запросом проверять будет он долгим или нет - ясно, что так делать никто не будет. А тут механизм, который ограничивает сложность выполняемых запросов - можно сделать сайт, на котором в 99% случаев не будет работать поиск. Поиск будет работать только если заданный запрос удобен для поиска при существующих индексах, а иначе выдаст не все результаты (а вообще непонятно сколько). Как применение: можно таким образом ограничивать возможности поиска для анонимов, например.

Неактивен

 

#3 03.01.2014 17:32:05

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

rgbeast написал:

Я так понял, что сделано для экономии времени. Совершенно неканонично перед каждым запросом проверять будет он долгим или нет - ясно, что так делать никто не будет.

По сути это и так делается на этапе составления плана выполнения, когда считается стоимость того или иного плана: оценочное число прочитанных строк из таблиц, коэффициенты на различные операции типа группировок, сортировок, объединений. Просто стоимость считается в абстрактных величинах, но ничто не мешает посчитать ещё одну формулу для оценки числа строк после того как выбран план и только для тех запросов где указан ROWS EXAMINED.


rgbeast написал:

А тут механизм, который ограничивает сложность выполняемых запросов - можно сделать сайт, на котором в 99% случаев не будет работать поиск. Поиск будет работать только если заданный запрос удобен для поиска при существующих индексах, а иначе выдаст не все результаты (а вообще непонятно сколько). Как применение: можно таким образом ограничивать возможности поиска для анонимов, например.

Нехорошо проводить дискриминацию по цвету ника. Тогда уж лучше запретить анонимам пользоваться поиском.
Пришел юзер, ткнулся в поиск, ничего не нашел и, решив, что сайт унылое г, ушел. Если с него потребовать регистрацию, он тоже уйдет, но если ничего не найдет, то вернется и зарегится.


Придумал способ использования.
На сайте сложная форма поиска, например, каталог авто-запчастей с кучей параметров. С ростом базы/посещаемости сайт начинает тормозить и тогда админ вместо того, чтобы заказать оптимизацию производительности, подкручивает параметр ROWS EXAMINED в скриптах smile
Всё работает быстро, а проблемы юзеров, админа не волнуют.

Неактивен

 

#4 03.01.2014 17:38:34

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3878

Re: LIMIT ROWS EXAMINED

vasya написал:

На сайте сложная форма поиска, например, каталог авто-запчастей с кучей параметров. С ростом базы/посещаемости сайт начинает тормозить и тогда админ вместо того, чтобы заказать оптимизацию производительности, подкручивает параметр ROWS EXAMINED в скриптах smile
Всё работает быстро, а проблемы юзеров, админа не волнуют.

Я примерно это и имел в виду - выбирайте запчасти с точки зрения оптимальности запросов MySQL. Но сразу же пришло в голову, что для админа и для платных подписчиков таких ограничений не будет. Унылость сайта будет очевидна всем, кто не может указать достаточно специфичный запрос, чтобы он быстро выполнялся.

Неактивен

 

#5 09.01.2014 14:01:26

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

Кстати, есть max_join_size, который как раз и посылает на этапе составления плана. Вот только неясно с чем именно он производит сравнение. Я полагал, что с предполагаемым количеством строк из столбца rows в explain, но


MariaDB [test]> set @@session.max_join_size=1;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from test;
ERROR 1104 (42000): The SELECT would examine more than MAX_JOIN_SIZE rows; check
 your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT i
s okay
MariaDB [test]> set @@session.max_join_size=3;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from test;
+------+-------+
| id   | name  |
+------+-------+
|    1 | a     |
|    2 | a     |
|    3 | b     |
|    4 | c     |
|    5 |  bb   |
|    6 | tort  |
|    6 | ort   |
|    6 | ortt  |
|    6 | tortt |
+------+-------+
9 rows in set (0.00 sec)

MariaDB [test]> explain select * from test\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 9
        Extra:
1 row in set (0.00 sec)

MariaDB [test]> set @@session.max_join_size=2;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from test;
ERROR 1104 (42000): The SELECT would examine more than MAX_JOIN_SIZE rows; check
 your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT i
s okay

Неактивен

 

#6 10.01.2014 23:51:43

Neval
Гуру
Откуда: Киев
Зарегистрирован: 11.03.2008
Сообщений: 449

Re: LIMIT ROWS EXAMINED

Не совсем уловил разницу между лимитами... стандартный лимит ограничивает количество записей уже после того как всё соединено, выбрано и отсортировано. А этот когда? Когда выбирается/соединяется?


Человек без чувства юмора - не серьёзный человек wink

Неактивен

 

#7 10.01.2014 23:59:17

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

А этот считает кол-во обработанных строк в процессе выполнения: прочитали из таблицы х строк; записали их во временную таблицу - значение счетчика стало 2х. Стали делать группировку методом файлсорт - стало 2х+у. И тут достигнут предел и выполнение запроса завершилось. А ведь в запросе могла быть ещё и сортировка, которая соответственно не выполнилась.

Неактивен

 

#8 11.01.2014 00:02:52

Neval
Гуру
Откуда: Киев
Зарегистрирован: 11.03.2008
Сообщений: 449

Re: LIMIT ROWS EXAMINED

Вооот, собственно из-за сортировки у меня возник тот вопрос))) Это наверн актуально для результатов поиска, нашли Х результатов, зачем ещё остальные искать, если всё равно на странице только Х отображается))


Человек без чувства юмора - не серьёзный человек wink

Неактивен

 

#9 11.01.2014 00:07:36

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

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

Неактивен

 

#10 11.01.2014 00:20:14

Neval
Гуру
Откуда: Киев
Зарегистрирован: 11.03.2008
Сообщений: 449

Re: LIMIT ROWS EXAMINED

Хм, т.е. если у меня в запросе джоин Х таблиц, то запрос прервётся при нахождении этого лимита записей в любой из них?


Человек без чувства юмора - не серьёзный человек wink

Неактивен

 

#11 11.01.2014 00:22:45

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

Нет, он может не успеть ничего найти smile
Это ограничение не количества выбранных таблиц, а кол-ва прочитанных, добавленных, измененных и удаленных строк во время выполнения запроса.

Неактивен

 

#12 11.01.2014 00:28:00

Neval
Гуру
Откуда: Киев
Зарегистрирован: 11.03.2008
Сообщений: 449

Re: LIMIT ROWS EXAMINED

О, слово "прочитанных" всё расставило на свои места, чё-то не обратил на него внимание в первом посте))) А как быть с остальными? Ведь обычный лимит тоже ограничивает количество добавленных, измененных и удаленных... В чём разница в данном случае? Допустим, при изменении и удалении есть условия, для этого "прочитываются" записи, вроде понятно)) А при добавлении какое поведение?


Человек без чувства юмора - не серьёзный человек wink

Неактивен

 

#13 11.01.2014 00:28:46

Neval
Гуру
Откуда: Киев
Зарегистрирован: 11.03.2008
Сообщений: 449

Re: LIMIT ROWS EXAMINED

Кажися и тут понимаю... строки временных таблиц тоже считаются?))


Человек без чувства юмора - не серьёзный человек wink

Неактивен

 

#14 11.01.2014 00:29:45

vasya
Архат
MySQL Authorized Developer
Откуда: Орел
Зарегистрирован: 07.03.2007
Сообщений: 5827

Re: LIMIT ROWS EXAMINED

Neval написал:

Кажися и тут понимаю... строки временных таблиц тоже считаются?))

Да

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson