Чем дальше тем хуже, чем больше offset в условии LIMIT тем дольше обрабатывается запрос

[Kotofey]

Здравствуйте! У меня есть запрос вида :

INSERT INTO tab (
field_1,
field_2,
field_3,
field_4
)
SELECT
o.field_1,                                                                                                                                                 
o_n.field_2,
`f` as field_3,
(SELECT `f1` FROM tab2 as i
WHERE i.field=o.field AND i.field1=o.field1
AND NOT EXISTS(SELECT id FROM tab2 as i2 WHERE i2.field3=i.field3)
GROUP BY i.field) as field_4
FROM tab2 as o, tab3 as o_n
WHERE  o.field=o_n.field
AND o.field1=o_n.field1
AND o.field3=0
LIMIT 700,100

И вот чем больше у меня offset тем дольше обрабатывается запрос, к примеру с 700 строки по 800 у меня обрабатывается 9 секунд, с 800 по 900 - 11 секунд,а вот с 0 по 100 пол секунды. Кто-то знает в чем дело? А то записей многовато будет и ждать так долго не вариант.
P.S. индексы где надо там стоят

 

[Kotofey]

Спасибо, разобрался, во время тестов для очистки использовал TRUNCATE table и не верно после этого работали индексы.

 

[fixxxer]

чем больше у меня offset тем дольше обрабатывается запрос

Это в любом случае так будет.

 

[Фанат]

Дело не в бобине лимите. А вот в этом:

с 0 по 100 обрабатывается пол-секунды.

Запрос вместо нормального джойна сделан из говна и палок. И по этой причине работает медленно, даже без учета чудовищного оффсета в 700 строк.

Я так понимаю, что при взгляде на EXPLAIN глаза будут кровоточить, файлсорты там небось резвятся в каждой строчке, друг дружку перепрыгивая.
Плюс аккуратнее надо c EXISTS

 

[fixxxer]

Это смотря какой mysql (и какой exists). В ряде случаев современные версии (MariaDB, MySQL 5.6.5+) умеют в semi-join optimization.

https://mariadb.com/kb/en/mariadb/documentation/optimization-and-tuning/query-optimizations/subquery-optimizations/subquery-optimizations-map/
http://dev.mysql.com/doc/refman/5.6/en/subquery-optimization.html

 

[Kotofey]

Запрос вместо нормального джойна сделан из говна и палок. И по этой причине работает медленно, даже без учета чудовищного оффсета в 700 строк.

Увы, но только этот запрос выполняет свою задачу!

 

[Kotofey]

Это в любом случае так будет.

Может быть, но пока наблюдаю обратное:

START ITERATION # 8  ORDER FROM  700  TO  800
FINISH ITERATION # 8  TIME:  2.01746177673
WAIT second....
START ITERATION # 9  ORDER FROM  800  TO  900
FINISH ITERATION # 9  TIME:  2.03540802002
WAIT second....
START ITERATION # 10  ORDER FROM  900  TO  1000
FINISH ITERATION # 10  TIME:  2.02067685127
WAIT second....

 

[Фанат]

Фикс имел в виду значимые офсеты.
На первых тыщах разумеется никакой разницы.

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

 

[Kotofey]

Фикс имел в виду значимые офсеты.
На первых тыщах разумеется никакой разницы.

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

На первых десяти "тыщах" тоже нет разницы
А так спорить думаю бесполезно, Вы не знаете структуры таблиц и задачи которая стояла передо мной.

 

[Hello]

Увы, но только этот запрос выполняет свою задачу!

запросы в цикле тоже выполняют свою задачу

 

[Фанат]

На первых десяти "тыщах" тоже нет разницы
А так спорить думаю бесполезно, Вы не знаете структуры таблиц и задачи которая стояла передо мной.

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

 

[antson]

меня сильно смущает в конструкции insert - select наличие лимита и офсета
Если цель разбить тяжелый запрос на части, то таким способом ситуация становится наоборот катастрофической.
так как серваку в результате приходится делать делать одну и туже работу многократно.

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

 

[Kotofey]

меня сильно смущает в конструкции insert - select наличие лимита и офсета
Если цель разбить тяжелый запрос на части, то таким способом ситуация становится наоборот катастрофической.
так как серваку в результате приходится делать делать одну и туже работу многократно.

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

Запрос без лимитов работает 3 секунды

 

[Kotofey]

Вопрос закрыт, в запросе убрал лимит!

 

[antson]

(select ) as field_4 посади в базу тестовые данные, чтобы субзапрос возращал больше 1 строки.