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

инфа о таблицах: projects - примерно 700к записей
users - примерно 90к записей
подзапрос отдельно исполняется около 0.4 секунды

вот собственно сам обрезок запроса о котором идет речь

select
projects.id as id,
users.username
from projects
left join users ON users.id=projects.userid
left join
(SELECT
parent_id,
sum(if(`upload_type`='EMBED_FILL',1,0)) as F2Ldocuments
FROM projects
where `upload_type`='EMBED_FILL' group by parent_id) as fill
on `projects`.`id` = `fill`.`parent_id`
where `username` != ''
group by projects.userid

если убрать group by, то запрос исполняется примерно 0.7 секунды если же добавить group by то запрос висит на протяжении 30-ти секунд и я его сам убиваю.

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


...у вас база очень долго думает, а какое Project_id
надо AndriyNifler-у если случится несколько ?
над этим он думает первые 15 секунд, а потом база размышляет --
а что собствено хотел подсчитать AndriyNifler в группировке?

но через 30 секунд вы его вырубили и mysql
так и остался в непонятках...

miksoftretvizanКак MySQL может воспринимать его как коррелированный?Я вот тоже думаю, что дело не в этом.
Скорее в том, что он материализируется во временную таблицу, но индекса по ней нету. И он стоит в правой части LEFT JOIN-а, т.е. не может быть ведущим. Т.е. проверка каждой записи требует полного сканирования временной таблицы.


...кстати, в версии 5.7 добавили автоматическое (!)
динамическое построение индекса
как раз для такого случая...

AndriyNiflermiksoftпропущено...
Я вот тоже думаю, что дело не в этом.
Скорее в том, что он материализируется во временную таблицу, но индекса по ней нету. И он стоит в правой части LEFT JOIN-а, т.е. не может быть ведущим. Т.е. проверка каждой записи требует полного сканирования временной таблицы.

Но если это так, то оно должно было б обрабатываться долго и без group by. Но без этой команды все очень быстро проделывается. Может быть так, что group by работает не с резуьтатом запроса, создавая из него новую таблицу, а постоянно сортирует и присоединяет нужные записи прямо во время составления таблицы результата? и в таком случае подзапрос будет выполняться каждый раз при создании новой строки.
не слишком ведущ в mysql, так что не сильно щемите, если то что сказал является очевидным бредом.


достаточно многое можно понят применение EXPLAIN.
прогоните простой и группированый запрос через ЕКСПЛАЙН
и покажите сюда результаты...

AndriyNifler,


popkazhite resultat:

SHOW CREATE TABLE projects;

SHOW CREATE TABLE users;

....vozmozhno, nado dobavit' index projects.parent_id

AndriyNiflerили реально так заджоинить с 4 таблиц данные, вместе с некоторыми функциами типа count, summ, if чтобы работало с такими огромными объемами данных и делало выборку хотя б за секунд 20?


....50 на 50 ... или да или нет...