Логика системы продажи билетов

В настоящее время у нас есть система управления билетами, и, как и все системы продажи билетов, она должна распределять обращения между агентами в циклическом порядке. Кроме того, в то же время агент может применять свою собственную логику фильтрации и работать со своей очередью.

Эта проблема,

1. Таблица с билетами сейчас очень большая, занимает более 10 миллионов строк.
2. Один билет никогда не должен назначаться двум разным пользователям.
3. Чтобы решить указанную выше проблему, у нас есть поток,
4. Запрос на выбор запускается с критериями фильтрации и ограничением 0,1
5. Затем строка, возвращаемая указанным выше запросом, выбирается на основе идентификатора и блокируется для обновления.
6. Наконец, мы запускаем обновление, говоря, что пользователь X выбрал дело.
7. Пока выполняется шаг 3, другой пользователь не может получить блокировку для того же случая, поэтому они запускают 3. запрос может быть несколько раз, чтобы получить следующий доступный случай.
8. По мере увеличения количества пользователей это время на шаге 4 становится все больше и больше.

Мы пробовали сделать выбор для обновления в запросе на самом шаге 4, но это замедляет весь запрос. Предполагая, что это связано с огромным количеством строк в запросе выбора.

Вопросы,

• Есть ли вообще другой подход?
• Обеспечит ли выбор и обновление в хранимой процедуре те же результаты, что и выбор для обновления, а затем обновление?