如何在单个事务中手动释放表的UPDLOCK锁？

在SQL Server中，UPDATE语句执行时会将UPDLOCK转换为排他锁（X锁），这类锁的生命周期与事务绑定，无法在事务中途主动释放锁同时保留已完成的修改——这是ACID事务特性的要求，目的是保证数据的一致性和隔离性。

如果你的核心需求是让其他事务能访问被锁的资源，可根据场景选择以下方案：

方案1：开启快照隔离让其他事务读取快照 #

若只需让其他事务读取该行数据（无需修改），可开启数据库的READ COMMITTED SNAPSHOT ISOLATION（RCSI）。开启后，其他事务会读取该行的快照版本，无需等待锁释放，但仍无法修改该行，直到当前事务结束。

开启RCSI的语句：

ALTER DATABASE YourDatabaseName SET READ_COMMITTED_SNAPSHOT ON;

方案2：用应用锁替代表行锁，实现中途释放 #

如果需要让其他事务能修改该行，同时保留当前事务的完整性，可以使用SQL Server的应用锁（sp_getapplock/sp_releaseapplock）替代行级UPDLOCK。应用锁由用户自定义资源标识，可在事务中途主动释放，且不影响事务的持续执行。

示例代码：

BEGIN TRAN

-- 获取针对目标行的应用锁，LockOwner指定为Transaction绑定到当前事务
EXEC sp_getapplock 
    @Resource = 'table_x_row_z_a', 
    @LockMode = 'Update', 
    @LockOwner = 'Transaction'

-- 执行更新操作，无需再加UPDLOCK
UPDATE table_x
   SET x = y
WHERE z = a

EXEC process_stuff @input_parameters

-- 主动释放应用锁，其他事务即可获取该锁操作目标行
EXEC sp_releaseapplock 
    @Resource = 'table_x_row_z_a', 
    @LockOwner = 'Transaction'

EXEC process_other_stuff @input_parameters

COMMIT TRAN

注意：应用锁的资源标识（@Resource）需要自行维护，确保能精准对应到目标行或资源，避免锁范围过大或过小。

方案3：调整事务流程（不满足单事务要求） #

如果允许拆分事务，可将UPDATE+process_stuff作为第一个事务提交，再开启新事务执行process_other_stuff，但这不符合你“所有操作在一个事务内”的要求，仅作备选。

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