删除大量数据库数据时，read uncommitted是否适用？对写入有影响吗？

先明确：Read Uncommitted对删除操作的锁行为无影响 #

你设置的read uncommitted是读隔离级别，仅控制当前会话中读取数据的规则（允许读取未提交的脏数据），但完全不会改变DELETE操作本身的锁策略。SQL Server中，删除操作默认会对目标行加排他锁（X锁），若删除行数过多触发锁升级，还会升级为表级排他锁——这才是影响其他写入用户的核心原因，和你设置的读隔离级别无关。

对写入用户的实际影响 #

无论使用哪种读隔离级别，批量删除大量数据时：

• 若触发表级锁，其他用户对temptable的写入操作（插入、更新、删除）都会被阻塞，直到你的删除事务完成。
• 即便未触发锁升级，大量行级排他锁也会加剧锁竞争，拖慢其他写入操作的速度。
  read uncommitted不会减轻这种影响，它只是让你自身会话的读操作不受其他事务的锁限制，但你的删除操作对其他用户的阻塞情况完全不变。

更优的优化方案（不止于隔离级别） #

若要降低对其他用户的影响，重点不是更换读隔离级别，而是优化删除方式：

• 分批删除：将大删除拆分为多次小批量操作，比如每次删1000行循环执行，避免锁升级。示例代码：

USE MyDatabase
SET NOCOUNT ON
DECLARE @RowsDeleted INT = 1
WHILE @RowsDeleted > 0
BEGIN
    DELETE TOP(1000) FROM temptable WHERE mark = 2023
    SET @RowsDeleted = @@ROWCOUNT
    PRINT 'Deleted ' + CAST(@RowsDeleted AS VARCHAR(10)) + ' rows'
END

• 启用快照类隔离：若数据库允许，开启READ_COMMITTED_SNAPSHOT或ALLOW_SNAPSHOT_ISOLATION，这样其他用户的读操作不会被你的删除锁阻塞（会读取数据的快照版本），虽无法消除写入操作的阻塞，但能减少一半锁冲突场景。
• 分区切换：如果temptable是分区表，且mark=2023恰好对应一个独立分区，可直接将该分区切换到临时表后再删除，这是最快且影响最小的方式，但需要提前做好分区设计。

如果非要选一个更合适的隔离级别，**Read Committed（默认级别）**就足够——它不会让你读取脏数据，同时对删除操作的锁行为和read uncommitted完全一致，毕竟隔离级别管控的是读逻辑，而非写操作。

内容的提问来源于stack exchange，提问作者Stacey