Ну я же написал что не в коня корм, а вы продолжаете спорить... СУБД - это сетевой ресурс, поэтому любое предположение, что "вот этот конкретный кусок кода владеет этим ресурсом монопольно" априори неправильное, поэтому да, код для работы с БД нужно писать всегда из расчета того, что данные меняются, вот тут чувак довольно ржачный тезис выразил:

https://sqlperformance.com/2014/04/t-sql-queries/the-serializable-isolation-level Much production T-SQL code is written with the implicit assumption that the underlying data will not change during execution Более того, в вашем MSSQL настройки по-умолчанию таковы, что там совершенно непонятно что происходит:

https://sqlperformance.com/2014/04/t-sql-queries/the-read-committed-isolation-level The short-term shared locks used by the SQL Server locking read committed implementation provide very few of the guarantees commonly expected of a database transaction by T-SQL programmers. In particular, a statement running under locking read committed isolation:

-Can encounter the same row multiple times;
-Can miss some rows completely; and
-Does not provide a point-in-time view of the data

т.е. при настройках по-умолчанию в MSSQL нет даже контракта Statement-Level Read Consistency , а вы меня пытаетесь уверить, что в вашем, так называемом, алогоритме последовательный запуск разных запросов обеспечит некую консистентность (мое минимальное ожидание такое, что будут вычитаны все данные) - это нифига не так.

то что данные в таблицах должны кластеризовываться по значению PK - это вообще бред сивой кобылы: в абсолютном большинстве случаев отношение порядка для PK вообще никаких бизнесовых функций в себе не несет, т.е. мы даже не можем сказать, что если одно значение PK мажорирует (это термин из мат. анализа, если что) другое, то это означает, что пользователю нужно соответствующие строки показывать именно в этом порядке - отношение порядка в PK нужно исключительно для СУБД, чтобы она могла понять каким образом формировать BTree-индекс, а как только пользователь в запросе "указал where или order by" все эти рассуждения насчет упорядочивания значений PK улетают в трубу. В кластеризации данных в таблице по значению PK в абсолютном большинстве случаев нет никакого смысла, потому что на практике все пользовательские запросы эту выдуманную конвенцию нарушают, т.е. получается так, что в этом случае в базе мы строим некоторую структуру (и еще вынуждены ее поддерживать и получать безумные накладные расходы, например, в виде постоянных Bookmark Lookups и блокировок в MSSQL или переупорядочивании данных на вставках), которая совершенно неэффективна для пользовательских запросов, именно поэтому в Oracle, в случае OLTP, использование IOT - это довольно-таки редкий случай, а в PostgreSQL кластеризация данных в таблице - это maintenance операция.

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




работает в 20 раз быстрее их супер-крутого алгоритма