我的应用程序需要批处理 10M 行，这是连接表的复杂 SQL 查询的结果。
我将计划迭代一个结果集，每次迭代读取一百个。
为了在繁忙的 OLTP 生产数据库上运行它并避免锁定，我想我将使用READ UNCOMMITTED 隔离级别进行查询。
这会使查询不受任何数据库写入的影响吗？避免任何行/表锁？
我主要关心的是我的查询阻塞了任何其他数据库活动，我不太关心其他方式。
旁注：
1. 我将阅读历史数据，所以我不太可能遇到未提交的数据。如果我这样做也没关系。
2. 迭代过程可能需要数小时。数据库连接将在此过程中保持打开状态。
3. 我最多有两个这样的并发批处理实例。
4. 我可以容忍重复行。（通过读取未提交的产品）。
5. DB2 是目标数据库，但我也想要一个适合其他数据库供应商的解决方案。
6. 快照隔离级别能帮我清理服务器内存吗？
你真的遇到过真正的读锁吗？
就我而言，SQL 标准中存在 READ UNCOMMITED 的唯一原因是允许非锁定读取。所以我不了解 DB2，但我盲目地打赌它在 READ UNCOMMITED 模式下读取期间不会锁定数据。然而，大多数现代 RDBMS 系统在读取 (*) 期间根本不会锁定数据。所以 READ UNCOMMITED 要么不可用（例如在 Oracle 中），要么被默默地提升为 READ COMMITED (PostgreSQL)。
如果您可以自由选择引擎，请检查 DB2 事务隔离级别处理或选择 Oracle/PostgreSQL/其他。
(*) 更准确地说，它们不会专门锁定数据。一些共享锁可以放置在查询表上，因此在读取期间没有 DDL 更改它们。
我的回答适用于 SQL Server。
读取提交的每行读取（大约）后释放锁定。锁定可能不是您的问题。
我建议您使用更安全的READ COMMITTED. 更好的是，使用快照隔离。这消除了许多锁定问题。也有缺点，所以你最好读一点。
我主要担心的是我的查询阻塞了任何其他数据库活动
快照隔离使只读事务的所有锁定问题都消失了。无阻塞，数据完全一致。请注意，长时间运行的事务可能会导致 TempDB 填充快照版本。
数据库连接将在此过程中保持打开状态。
这是一个问题，因为网络中断、应用程序部署或镜像故障转移会终止您的批处理过程。
请注意，未提交的读取可能会导致查询偶尔完全失败。您需要重试逻辑或容忍失败的作业。
在 sql server 事务隔离级别读取未提交导致表上没有锁定。