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

[флоппик]

Этот вариант гарантированно не подойдет, нам надо плясать от заказов, ограниченных датами.

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

 

[флоппик]

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

 

[AnrDaemon]

внешний запрос выводит 3 записи, на каждую из которых запускается подзапрос с count на каждую из записей, нет?

Читал запрос по диагонали… посыпаю голову пеплом.
Может сработать.

 

[Yoskaldyr]

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

 

[Фанат]

t.device - это строка.
3 rows in set (3.10 sec)
| Copying to tmp table | 3.092709 |

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

 

[Yoskaldyr]

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

 

[Фанат]

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

Ну, если я заменяю device на left(t.device,1) то скорость не меняется...
Хотя возможно он этот лефт уже применяет к резальтату выборки.
В любом случае, я думаю что основная проблема здесь - количество строк

 

[Yoskaldyr]

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