Mysql Оптимизация запроса с group by по полю из джойна

флоппик

promotor fidei
Команда форума
Партнер клуба
Этот вариант гарантированно не подойдет, нам надо плясать от заказов, ограниченных датами.
Я не сразу понял, что просто это название таблицы вводит в заблуждение. Это не таблица products, это таблица sales_products, элементы заказа. Поэтому-то все рекомендуют по продактс группировать.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Вообще, если не хочется денормализацию, я бы сделал партиционирование по датам в sales, порезав на часто используемые сегменты (месяц? неделя? n-дней?), что бы получить выгоду от сегментирования выборок по дате. Но это так, пища для ума, например.
 

Yoskaldyr

"Спамер"
Партнер клуба
А какой профиль запроса (profile а не explain)? Т.е. сколько процентов времени тратится на каждую внутреннюю операцию.
Просто иногда временные таблицы не такое зло, как объем копируемых в них данных.
t.device - это строка или числовой ид?
 

Фанат

oncle terrible
Команда форума
t.device - это строка.
3 rows in set (3.10 sec)
| Copying to tmp table | 3.092709 |

во временную таблицу льётся 2 миллиона записей
 

Yoskaldyr

"Спамер"
Партнер клуба
У девайса есть id? или что-то более короткое чем строка?
Т.е. задача чтобы во временной таблице не было ничего большого, только id-шники, чтобы к конечной выборке сделать join необходимых данных (это при условии что временная таблица все равно создается).
 

Фанат

oncle terrible
Команда форума
У девайса есть id? или что-то более короткое чем строка?
Т.е. задача чтобы во временной таблице не было ничего большого, только id-шники, чтобы к конечной выборке сделать join необходимых данных (это при условии что временная таблица все равно создается).
Ну, если я заменяю device на left(t.device,1) то скорость не меняется...
Хотя возможно он этот лефт уже применяет к резальтату выборки.
В любом случае, я думаю что основная проблема здесь - количество строк
 

Yoskaldyr

"Спамер"
Партнер клуба
500-600К строк это не много
чем профайлинг хорош, что с его помощью сразу видно где затык и можно ли его оптимизировать.
Копирование во временную таблицу - можно оптимизировать, если уменьшить количество передаваемых туда данных (и обычно время уменьшается пропорционально уменьшению передаваемых данных).
Самый простой вариант - сделать запрос не возвращающий текст - только идшники (если такие есть). А потом уже усложнять джоином к результату ответа этого проверенного запроса. Т.е. сначала проверить что INNER JOIN условия не тупят
 
Сверху