Есть главный домен example.com, он служит для регистрации, логина и восстановления пароля.
Есть несколько субдоменов вида xxx.example.com и yyy.example.com на которых расположены разные сервисы, которые используют свои БД.

Все сайты объеденены общей авторизацией (залогинившись на одном сайте, автоматом логинимся везде).

Другие сайты взаимодействуют с основной БД в 2 случаях:
1) При входе на сайт выбираются данные пользователя для хранения в сессии
2) При каждой загрузке страницы обновляется параметр last_activity у пользователя, чтобы контролировать онлайн
3) При редактировании личной информации на любом сайте, обновляются данные пользователя основной БД

Сейчас таблица пользователей состоит из ~40 полей.
Я задумался в разделении этой таблицы на отдельные таблицы пользователей для каждой БД.
Чтобы все сервисы взаимодействовали с основной таблицей пользователей только для самый важных данных (логин, имя, пароль, емейл, время последней активности).

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

Вопрос: как лучше организовать новую таблицу пользователей для конкретного сервиса, чтобы избежать постоянных проверок на наличие пользователя в базе.

Что, никаких идей?

Для чего вообще таблицу разбивать на несколько? Чтобы затем выбирать все данные join'ами?

Просто сейчас это 3 сервиса и 40 полей пользователя, потом будет 5 сервисов и 60 полей, выходит как-то многовато, да и по нагрузке все сервисы будут постоянно обращаться к основной базе, что не есть хорошо.

Не нужно каждый раз дергать базу, вытащили данные пользователя (insert если первый визит), положили в сессию

Я так и делаю, просто есть поле last activity, которое постоянно обновляется.
Я не могу его вытащить в другие базы, т.к. параметр "user online" относится сразу ко всем сервисам.