Особенности хранения данных с учетом различных соц сетей

[Crazy]

...и за время сессии никто не селектит информацию по социальным сетям? Только при логине?

Далее: если мы отдельно рассматриваем новых пользователей, то логичен вопрос: каков процент новых пользователей?

[aimatme]

за время сессии - да никто не селектит - она кешируется и отдается из кеша
по проценту наверное сложно сказать, но ориентируюсь на цифру до 10 регистраций в секунду в качестве максимальной нагрузки

[Crazy]

Поскольку Вы используете InnoDB, то если обернуть операции вставки/обновления в транзакцию, то не должно быть существенной разницы -- одна у Вас таблица или несколько.

Так что я бы в Вашем случае сделал несколько таблиц. Далее: если планируется делать выборки с фильтрацией по информации из социальных сетей и, соответственно, будут индексы по обновляемым полям, то имеет смысл таблицы с данными разделить (partitioning) на сегменты "поперек" по пользователям. К примеру, делаем 8 сегментов и распределяем записи по ним согласно 3 младшим битам id пользователя (считаем, что id записи совпадает с id пользователя) -- это даст существенную экономию на перестройке индексов.

BTW, перед реализацией рекомендую провести нагрузочный тест.

[aimatme]

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