Dwrчто-то похожее я и сделал. Но тогда в sum(value) кладутся вообще все транзакцииЗначит, сделал совершенно непохожее. Будь внимательнее.

Покажите свой запрос, что ли...

Ну! а я что говорю... Где в твоём запросе, жёваный крот, группировка? перепроверил он...

retvizanОкончательный запрос нужен вида
.. from info join (подзапрос с группировкой) ..А вот это уже с потолка взято.

retvizanПочему?
Джойнить, а потом проводить группировку по текстовому полю первой таблицы - плохое решение с т.з. производительности.
Ну например потому, что при объёмном результате подзапроса он будет закэшен на диск.
Или потому, что прощай использование индекса. Вернее, и.
В общем, оверхед запросто может стать пухлее профита. А на реальной базе указанного назначения - гарантированно станет.

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

Кстати, с какого потолка взято, что группить он собрался по тексту?

[quot DwrCOUNT() глупости какие-то показывает...[/quot]
COUNT(DISTINCT info.id)

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

retvizanЗдесь и так связь таблиц не по индексу.
Таблицы, DDL коих приведены - не более чем модель, ТС об этом говорит. На боевой системе индексы просто обязаны появиться, чтобы получать результат за вменяемое время.

retvizanAkinaВ общем, оверхед запросто может стать пухлее профита. А на реальной базе указанного назначения - гарантированно станет.Прошу пояснений.
overhead - в данном случае дополнительные затраты ресурсов (в первую очередь времени);
profit - экономия ресурсов (тоже в первую очередь времени).

retvizanгруппировка по ней всегда файлсорт, даже при наличии индекса на `unique_field`.
Не знаю досконально начинки сервера и того, что именно он выберет для выполнения запроса, но группировка-то идёт по моему разумеению всё-таки не по тексту. ТС говорит про какой-то "число-буквенный код", но в структурах модели его нет, так что в этой точке мысль просто останавливается. А если потом окажется, что это некое уникальное (это указано явно) текстовое поле первой таблицы - то в процессе оптимизации ему воленс-неволенс придётся перейти на группировку по первичному индексу.
Сортировка же конечного набора по групповой функции SUM() - да, по-любому файлсорт, куда деваться.

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

.. info join (select ..transactions .. group by ..) order by...

В случае сортировки в подзапросе она просто будет сервером проигнорирована.

Во-вторых, при наличии покрывающего индекса в первом варианте к таблице транзакций вообще не будет обращений.

И в очередной раз повторюсь - group by unique_field в любом случае есть БСК. Правда, в зависимости от того, из какой он таблицы, это будет разный БСК. Группить надо по первичному ключу.

retvizanПочему проигнорирована? Можно ссылку?
Под "сортировка учитывается" мы понимаем "ретранслируется в результат", так? впрочем, если нет - то я вообще не понимаю, о чём идёт речь...

Про то, что это не файловая БД, уже сказали. Но попробуй минимально включить логику.

Допустим, порядок сортировки в подзапросе учитывается (непонятно, как, но допустим). Теперь представь, что у тебя ДВА подзапроса, и в каждом своя сортировка...

retvizanMySQL выполняет запрос последовательно: join, where, group by, having, order by, limit.Ты не поверишь, но это НЕ ТАК. Вот если полностью заблокировать оптимизатор - то да, но кому такой сервер будет нужен?

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