не пишите в мускуле кореллированные подзапросы, если в этом нет острой необходимости

ну ты сам написал

почти все можно через join сделать

сджойнить

ну и вот получаются твои посты

после группировки получается нематериализованная сущность "посты с количеством ссылок"

SELECT count(l.id) as cnt, p.name FROM post p INNER JOIN link l ON p.post_id = l.post_id AND p.author_id = l.author_id WHERE p.forum_number = 36 GROUP BY p.name HAVING cnt > 10 ORDER BY p.updated_at DESC LIMIT 80;

как то так?

я думаю, группировать стоит все-таки по айдишнику

а ну да, точно

ну а так - в целом это имелось ввиду?

ну а так - в целом это имелось ввиду?

да не слушай ты местных экспертов. с подзапросом читабельнее, а план в последних mariadb и mysql скорее всего такой же будет

но вопросы про правильность запроса лучше начинать с вывода EXPLAIN. сам не скажешь — тут же никто и не спросит ;)

SELECT count(l.id) as cnt, p.name FROM post p INNER JOIN link l ON p.post_id = l.post_id AND p.author_id = l.author_id WHERE p.forum_number = 36 GROUP BY p.name HAVING cnt > 10 ORDER BY p.updated_at DESC LIMIT 80;

а как при этом выбрать ещё и первую ссылку

тоесть не только один p.name

но и l.url

первый

нет, ну если внезапно нужна ещё и первая ссылка из другой таблицы, то да, таки join. ты ж нигде до этого не говорил

ну джоин то есть

один чёрт придётся в select писать select ?

просто в свой запрос добавь substring_index(group_concat(l.url SEPARATOR '|'), '|', 1)

что-то типа такого

если тебе первый урл нужен из всего списка

ну первый урл у каждого поста

а первый по какому критерию? по дате?

там в таблице link есть поле, start_post

тоесть по этому маркеру

вполне

тогда добавить внутрь group_concat order by

просто в свой запрос добавь substring_index(group_concat(l.url SEPARATOR '|'), '|', 1)

так вроде вытащило что нужно

или для оптимизации?

тогда добавить внутрь group_concat order by

order by start_post DESC?

есть пост

к нему есть куча ссылок

скорее asc

и только одна там со start_post = 1

тогда можно упростить

если у тебя всегда одна запись с флагом 1

да всегда

хотя

блин-всё же есть что не всегда.

тогда тот вариант тебе подходит

лучше оставить как есть? с group_concat

а оно так не имеет права вытащить запись с любым start_post?

тоесть как то ограничить чтобы из start_post ов в случае если больше одного-брал первый?

substring_index для этого там и стоит

substring_index для этого там и стоит

так а почему по этому индексу окажется запись с start_post = 1?

он же при простом джойне имеет право в любом порядке их вывести

хм

на момент когда я написал ему кусок кода я не знал по какмоу принципу ему нужен первый урл

не вводи человека в заблуждение

SUBSTRING_INDEX(group_concat(l.url SEPARATOR '|'), '|', 1)

где тут правильно добавить тогда чтобы из start_post первый брал?

если вдруг больше одного будет

SUBSTRING_INDEX(group_concat(l.url SEPARATOR '|' ORDER BY start_post DESC), '|', 1)

он в любом случае возьмет один урл, посмотри в документации что делают функции

первая знаю что

ты уже как то мне кидал её, я с помощью неё там лог разспарсивать начал

SUBSTRING_INDEX(group_concat(l.url SEPARATOR '|' ORDER BY start_post DESC), '|', 1)

чот ругается

на что ругается? я могу перепутать местами separator и order by, не помню так на вскидку их порядок следования

SUBSTRING_INDEX(group_concat(l.url SEPARATOR '|' ORDER BY start_post DESC), '|', 1)

а так можно было? ох, вот я старый

внутри group_concat... скинь целиком запрос

попробуй указать separator после выражения с order by

попробуй указать separator после выражения с order by

да -да

и должно взлететь

SELECT count(l.id) as cnt, p.name, SUBSTRING_INDEX(group_concat(l.url SEPARATOR '|' ORDER BY l.start_post DESC), '|', 1) FROM post p INNER JOIN link l ON p.post_id = l.post_id AND p.author_id = l.author_id WHERE p.forum_number = 36 GROUP BY p.id HAVING cnt > 10 ORDER BY p.updated_at DESC LIMIT 80;

махни местами separator и order by

ORDER BY l.start_post DESC '|' l.url SEPARATOR

так?

делал, то же самое

group_concat(l.url ORDER BY l.start_post DESC SEPARATOR '|' )

https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function%5Fgroup-concat

group_concat(l.url ORDER BY l.start_post DESC SEPARATOR '|' )

?

Спасибо

а вот все эти фунции

они на быстродействии сильно отражаются?

например грубо говоря-у поста будет 500 ссылок

да не слушай ты местных экспертов. с подзапросом читабельнее, а план в последних mariadb и mysql скорее всего такой же будет

вот это весьма спорно

хотя start_post отсекает

но вопросы про правильность запроса лучше начинать с вывода EXPLAIN. сам не скажешь — тут же никто и не спросит ;)

а вот с этим соглашусь

и там больше 10-20 не будет, и то редко

да не слушай ты местных экспертов. с подзапросом читабельнее, а план в последних mariadb и mysql скорее всего такой же будет

ну так я бы сюда не заходил) и не спрашивал, для этого чат вроде и нужен

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

они на быстродействии сильно отражаются?

Тебя в первую очередь должно волновать количество джойнов и сложность группировок. Но это все будет шустро работать, пока ты проставляешь в БД необходимые для этого индексы. Дальше уже с эксплейном работать.

но это не точно

сейчас проверяю выборку

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

чото есть накладки, посмотрю пока

Тебя в первую очередь должно волновать количество джойнов и сложность группировок. Но это все будет шустро работать, пока ты проставляешь в БД необходимые для этого индексы. Дальше уже с эксплейном работать.

да выполянется быстро джоины, индексы есть

Но это все денормализация и туда лучше не лезть, пока нет необходимости и все бегает на индексах.

там есть много всяких нюансов вроде порядка объединения таблиц, используемых индексов при объединении и так далее

Но это все денормализация и туда лучше не лезть, пока нет необходимости и все бегает на индексах.

я на основе предстоящих задач

кое что денормализовал заранее

как писать автора поста и автора ссылки

или к какой категории они относятся

чтобы иной раз просто не делать join и не лезть лишний раз

Господа, в продакшене база работает раза в 2 медленее чем стейдж под той же нагрузкой, подскажите как лучше помониторить