Форум пользователей MySQL

Ну тогда это уже не mysql будет, никому не дашь )
Было бы красиво сделать через агрегацию в запросе, но увы.
Функций агрегаций очень мало, сами же знаете.
Я бы для начала group_concat дополнил LIMIT-ну очень часто хочется.

Никто, кроме скорости. Если мне нужно по 3 айдишника, а оно мне  коллекцию из 30 штук соберет-ничего хорошего, сами понимаете. так как размеры int весьма широкие. Ну а определить min max по полю, размер цифры в символах, плясать от этого-это уже большой велосипед. Очень я не люблю  поддерживать такое или баги в таком искать-увольте. уж лучше цикл.

Вопрос такой-как вы бы стали решать, из опыта именно с mysql работы.
`a`,`b`,`c` . Нужно для каждого уникального `b` найти `a`,`b`,`c` где `c` максимальное(если несколько, то любую).
Вернуть только 30 штук, сортированные по убыванию `c`
варианты
1)SELECT * FROM  (SELECT `b`, max(`c`) as `max_c` group BY  `b`) as `new` LEFT join `table` on  `max_c`=`c`,`b`=`b`  ORDER BY `max_c` DESC LIMIT 30
минус-что много данных достанет лишних. LIMIT нельзя внутри, значит много.
Using index for group-by для внутреннего запроса, но все равно 0.08 работает.
2) Просто сортировка по `c`(индекс есть) и выбираем в цикле mysql уникальные по `b` сверху вниз.
минус-что пройдет много  данных по индексу, если `b` сильно неуникальное.
3) что-то еще.
У меня 2 побыстрее 1 выходит

составной индекс на `b`,`c`, вроде бы идеален, верно?
Хотя можно `b`,`c`,`a`-вся инфа поднимется из индекса тогда.
INNER JOIN vs LEFT JOIN?  никакой разницы  в данном случае, хотя идейно вы, безусловно, правы.

Ага, спасибо.
А в mysql реализуется как-то более-менее логично структура типа хэша в хранимых процедурах ?
ну то есть что бы типа $a{key}=value и наличие по ключу быстро определялось
А то есть у меня мысль, но у больно дико получится.

Ну это я и решил, что оно. Там индексы-это хэш, но это все равно медленно будет. Потестим, сравним )