Ну, join'ить это дело можно (подозреваю что там ещё и union'ом прийдётся заливать), но так обычно не делают, потому что это решение потом невозможно будет отмасштабировать. Запрос тяжелый, кеширование поможет плохо, так как активность большая и кеш часто сбрасываться будет и база будет дергаться не многим меньше, ну и если базу надо распилить на 2 и больше серверов, то останемся лапу сосать с join'ами.
Для начала можно сделать так - для конкретного `user_id` (владелец новостной ленты):
1) Первым запросом стягиваем айди всех друзей
2) Вторым запросом стягиваем айди всех групп, в которых состоит
3) Третьим запросом стягиваем из comments все записи WHERE `user_id` IN (группы + друзья) ORDER BY/LIMIT по вкусу.
Преимущества:
Меньшая нагрузка на базу, она будет делать меньше дорогостоящих операций с временными таблицами. По индексам быстрее будет отдавать результат.
Первые 2 запроса можно спокойно закешировать, так как добавляются/удаляются друзья гораздо реже, чем сами посты. Потому по сути сводится всё к одному запросу на сами посты без join'ов.
Минусы:
Больше кода на обработку 3х запросов. Чуть более длительное выполнения скрипта, что, в принципе, не будет ощущаться пользователем, и вообще будет не справедливо, если первые 2 запроса кешировать.
Но если стоит задача масштабироваться, то и такого подхода к делу недостаточно. Там уже надо будет скорее всего жертвовать лишним местом, чтобы сократить расходы на собирание размазанных данных по всем серверам баз, например, вести отдельную таблицу ленты новостей для каждого пользователя, которая будет агрегировать все необходимые айдишники.
UPD: ...как и указал
@jarvis