Здравствуйте.
Прошу помощи в такой задаче.

Идея в следующем: Есть 2 таблицы пользователей с одинаковой структурой (активные и неактивные) и 2 таблицы с токенами, также одинаковой структуры, соответственно принадлежащие активным и неактивным пользователям. Все таблицы InnoDB.

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

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

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

Вопрос: как это правильно организовать с точки зрения многопоточности и высокой нагрузки?
Чтобы в тот момент когда юзер с токеном переносится из одной таблицы в другую, вдруг приходит еще один авторизационный токен от этого юзера. Получится что в активных его ЕЩЕ нет, а в неактивных - УЖЕ нет.

На ум приходит только блочить все 4 таблицы. Не получится ли что они будут постоянно заблочены?
Использовать транзакции? Как корректно выстроить логику коммитов и ролбэков? Я пока не силен в транзакциях.

vkleЕсли сначала инсертить запись в таблицу активных, а потом удалять из неаткивных, тогда вроде с логикой все в порядке.

Ситуация такая: приходят одновременно 2 запроса от неактивного пользователя:
- запрос 1 не нашел активного токена в момент t1, нашел в неактивных токенах в момент t2, начал перенос юзера между таблицами.
- запрос 2 не находит активного токена в момент t1, начинает искать в неактивных, но и в неактивных его тоже нет, т.к. запрос 1 успел его уже перенести в активные.

vkle ИМХО в этом есть смысл только если количество неактивных пользователей на порядки больше чем количество активных.
Именно это и предполагается, что будет очень-очень много неактивных, но которых нежелательно удалять, и которые будут висеть мертвым грузом на активных юзерах. Логика приложения позволяет иметь пользователю по несколько аккаунтов.

Akina , почему вы так думаете? Разьве скорость выборки не зависит от кол-ва записей в таблице? Я думаю, что если хорошо отладить это механизм переноса юзеров + поиграть с параметрами, которые влияют на перенос юзера в неактивную таблицу, то можно добиться стабильно хорошего результата на неограниченном кол-ве юзеров в целом

AkinaДа, приблизительно того же эффекта, как и от деления на две таблицы, можно добиться, если ввести в структуру поле boolActive и выполнить partitioning by range по нему. При наличии where boolActive = const в условии отбора (не в составе комплексного условия!) оптимизатор будет сканровать только нужный раздел.

Не слышал про partitioning by range . Пошел гуглить..