Запрос:


PK( id_agent, id_connection, application, client, date , hour , minute)

Помогите расставить индексы.

Это сообщение отредактировал(а) tishaishii - 25.6.2012, 13:52

Приведите запрос в нормальный вид, уберите подзапросы из секции select.

core.agent(id)
core.connection(id)

фсо. Больше тут индексировать нечего 



Скаляр далеко не всегда хуже джойна. Если в результате группировки 100 тыщ записей схлопнется в 10, то скаляр после группировки будет лучше чем джойн до. Правда, тут, определенно, не тот стлучай.

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

Да запрос вообще весёлый... скажем, если после группировки по sw1.id_agent, sw1.id_connection в какой-то группе останется одна запись - сервер пошлёт лесом, не сумев поделить на ноль... 

Не пошлёт. 1/0 eq NULL и там есть coalesce. По поводу "не тот случай". Случай именно тот: count( agent ) * count( connection ) ~= 100, а count(wowza_arch) >= 8e5 и всё время прибывает (в сутки на 1e5).
Ну подзапросы добавил в запрос вместе с group by, так как MySQL такое беозбразие позволяет. Можно вычеркнуть.

То есть, мнение такое, что дополнительные индексы здесь не сработают и запросу лучше не станет?

Это сообщение отредактировал(а) tishaishii - 25.6.2012, 16:02

Не факт. Тут важно когда именно будет подтягиваться скаляр. Либо до аггрегации, либо после. Вероятнее всего, в этом случае, будет до аггрегации.


Если запрос тупит с закоментированными селект подзапросами, оптимизировать его врядли удастся.


Правда штоле?  

Правда-правда. Так что никуда не пошлё.
Подзапросы я уже сказал, что можно вычеркнуть.

Я бы вам рекомендовал все же тут поэксперементировать

Сколько будет

покажите вывод консоли

Zloxa, да, верно, это фича MySQL, документированная даже.

Круто!   

Над чем эксперементировать-то? Есть надежда задействовать ещё индексы?

Вобщем, я лучше буду придумывать всякие обходные пути с объектами СУБД.
Группировать данные на лету, например, в триггере каком-нибудь.
Спасибо!

Уже не надо. Акина все объяснил с рефом на доку.


Нет, нету.


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

Объяснил, что 1/0 eq NULL?
Причём здесь остатки счетов?
Троллинг, по-ходу.

Да. Это не общепринятая норма, на сколько я могу судить. MySQL скорее исключение. Это вело меня в заблуждение.


При том что это тоже, фактически, результат аггрегации. С теоретической точки зрения выделение отдельной сущности остатков или плана счетов избыточно в виду того, что это расчетная информация, находится в прямой зависимости от других сущностей, как документов. Однако с практической точки зрения, для ее расчета требуется не адекватно много ресурса, потому базу денормализуют, выделяют суррогатную сущность, получают проблемы с обеспечением согласованности данных.

Так и у вас. Если вам нужно иметь возможность быстро выбираться по аггрегированным данным, вам надо денормализовываться, преаггрегироваться, решать проблемы согласованности, просаживаться на модификации.


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

Ну вот я вовлёкся. Уже тема закрыта. А я увлечённо читаю и отвечаю.