Всем привет. Такой вопрос: необходимо заблокировать от выбора юзером Б записи в таблице, которые уже выбрал юзер А (на время работы транзакции Т).
Насколько я разобрался в объектах блокировки, я сам должен следить и не давать щупать заблокированные записи. А как можно сделать без гемора то, что я хочу?

Для примера возьмем таблицу sflight: юзер А выбрал 10 произвольных записей и что-то с ними делает. Юзер Б запускает ту же транзакцию и у него тоже выбираются 10 записей из sflight для обработки. Чтобы к нему не попали записи юзера А сейчас я читаю блокировки, заполняю range кучей записей ( sign = 'E' option = 'EQ' low = '123456' ) и с этой портянкой делаю селект.
Проблема в том, что если несколько человек будут ковырять по 500-1000 записей, выборка будет очень тормозить или вообще протухнет.

Собсна как это сделать лучше/правильно?

Запросы на неравно и правда плохо работают. Иногда лучше удалять результаты после выборки на стороне приложения.

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

Как мне кажется, это горе от ума. Это не нормальная ситуация, когда вы выбираете "любые 10 записей". Слабо представляю себе такой бизнес-процесс.

Ситуация: нужно вручную проверить несколько тысяч записей по нескольким отделениям (то, что не получается сделать автоматом). В каждом отделении проверяет несколько человек. Юзер А из отделения 1 выбрал, скажем, 500 из 3000 проблемных по отделению. Юзер Б тоже хочет проверить 500 записей. Чтобы он не проверял то же, что и юзер А, надо исключить "первые" 500 записей из результата запроса. Чтобы работало быстрее, выбираются все записи по отделению, удаляются 500 заблокированных юзером А, от полученного набора отрезаются 500 (в данном примере) и отдаются юзеру Б. И так далее.

Вопрос: как тогда оптимальнее поделить данные между пользователями?

Вариант 1:
максимально расщепить целевой пул записей (в вашем примере - 3000) по каким-либо критериям, кроме, например, номера отделения. Отрабатывать блокировку в рамках такой разбивки будет проще.
Вариант 2:
ввести "статус" проверки записи - использовать этот статус как дополнительный критерий (см. вариант 1). в том числе, вместо блокировки.
Вариант 3:
создать буферную таблицу, куда помещать все записи, нуждающиеся в проверке, но не обрабатываемые/обработанные пользователем. удобно комбинировать с вариантом 2.

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

Я солидарен с nicky555: получение дополнительной информации о бизнес-процессе позволит получить корректное разделение данных на части, с тем, чтобы обеспечить корректную конкурентную обработку.

В других функциональных областях и правда используются все перечисленные концепции. Но в данном случае тс не совсем не прав, что копает в сторону блокировок. По сути дела такой процесс реализован с документами типа заказ в логистике, только у тс это не 1 документ в транзакции, а сразу много. Добавить поле в таблицу, конечно вариант, но его тогда придется апдейтить (по тысячам строк) в рабочем порядке, чтобы получить функционал по сути похожий на блокировки.
Балансировка по каким то критериям - интересный подход. Остается только найти хеш фунцию, которая бы хорошо справилась с такой задачей, и еще бы умела понимать сколько пользователей (т.е. групп разделения) у нее в текущий момент работает.

Текущая задача - взять адреса абонентов из ADRC и связать их с базой ФИАС для последующей интеграции с жкх и прочей лабудой.

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

Вот тут я пока ничего не придумал

А что если выбирать не все записи по отделению, а только определённое количество = сколько записей хочет юзер + сколько блокировок стоит по таблице. Потом отбрасываем из массива заблокированные записи и отдаём юзеру сколько он хочет из оставшихся.