Куча count - возможно, но не join-ов.
SELECT
posts.id,
posts.name,
count(case when s_vk.social_name = 'vk' then 1 end) as count_vk,
count(case when s_vk.social_name = 'tg' then 1 end) as count_tg,
count(case when s_vk.social_name = 'ok' then 1 end) as count_ok,
count(case when s_vk.social_name = 'tw' then 1 end) as count_tw
FROM posts
LEFT JOIN socials as s_vk on s_vk.post_id = posts.id
GROUP BY posts.id, posts.name
В вашем случае для ускорения не подходит ни то, ни другое.
Нужно вести отдельную таблицу в качестве кеша с аналогичными полями:
posts_id,
count_vk,
count_tg,
count_ok,
count_tw
При возникновении события клика на соц. сеть - добавлять запись в socials, а также триггером плюсовать значение по полю кеш-таблицы (и предварительно создавать запись в этой таблице по post_id, если не было ранее событий).
Для необходимости сброса кеша нужно сделать хранимую процедуру для его перегенерации на основе данного запроса.
PS:
Еще бы разбить таблицу socials - на справочник соц. сетей:
id - идент. соц сети.
full_name - полное название соц. сети,
abbrev - аббревиатура, например, ОК, ВК и т.д.
tag_name - тех. название, например, ok, vk и т.д.
... - другие параметры соц. сети
И таблицу для фиксации кликов:
soc_click_events
id - идент. события,
post_id - идент. поста,
social_id - идент. соц. сети,
event_date - дата и время клика,
... - другие параметры клика
PPS:
В итоге, для фиксации событий клика и поддержания структуры базы в нормальной форме вы используйте три таблицы - posts, socials и soc_click_events.
Для решения статистических задач вы делаете отдельные кеш-таблицы и обслуживаете их либо триггерами, либо хранимыми функциями и процедурами, получая статистические данные из первичной структуры.
