READPAST 是 SQL Server 表提示，可跳过被行级排他锁或更新锁阻塞的行，但不能直接用于 UPDATE 语句的目标表；必须通过 SELECT WITH (READPAST) 子查询获取可更新行后再执行更新。
READPAST 是什么，它真能跳过被锁的行更新吗
READPAST 是 SQL Server 中的一个表提示（table hint），作用是在 SELECT 或 UPDATE/DELETE 语句中跳过当前被其他事务持有排他锁（X 锁）或更新锁（U 锁）的行，而不是阻塞等待。但它不能用于纯 UPDATE ... SET ... WHERE ... 语句本身跳过锁定行执行更新——必须配合子查询、CTE 或显式游标等结构，让“定位要更新的行”和“执行更新”两个动作分离。
常见误解是写成这样：
UPDATE Orders WITH (READPAST) SET Status = 'Shipped' WHERE OrderID = 123;这不会报错，但
READPAST 在此无效：SQL Server 不允许对目标表直接加 READPAST 提示做 UPDATE（会静默忽略，仍可能阻塞）。
正确用法：用 SELECT + READPAST 定位可更新行再 UPDATE
核心思路是先用 SELECT ... WITH (READPAST) 拿到一批未被锁的行主键（或其他唯一标识），再基于这些 ID 做批量更新。典型场景是后台任务批量处理待办订单，避免因某一行卡住而整批挂起。
- 必须使用子查询或 CTE 获取候选行集合，且该查询需带
WITH (READPAST) -
UPDATE语句的目标表不能直接加READPAST，但可以对子查询结果加 - 推荐用
TOP (n)控制每次处理量，防止长事务和锁升级 - 确保子查询中的
WHERE条件能走索引，否则READPAST可能跳过大量本不该跳过的行（扫描时遇到锁就跳，但逻辑上不该跳）
示例（安全批量更新）：
UPDATE o
SET Status = 'Processed'
FROM Orders o
INNER JOIN (
SELECT TOP (100) OrderID
FROM Orders WITH (READPAST)
WHERE Status = 'Pending'
ORDER BY OrderID
) t ON o.OrderID = t.OrderID;READPAST 的实际限制和容易踩的坑
READPAST 行为高度依赖隔离级别和锁粒度，不是万能跳过锁的开关：
- 只跳过行级锁（
ROW），对页级（PAGE）或表级（TAB）锁无效 —— 如果发生锁升级，整个页/表被锁，READPAST就会跳过所有行 - 在
READ COMMITTED SNAPSHOT或SNAPSHOT隔离级别下，READPAST无意义（因为默认不加共享锁） - 不能跳过意向锁（
IX）、架构锁（SCH_S）等元数据锁，DDL 操作期间整个表可能不可读 - 如果子查询没加
ORDER BY，TOP结果不确定，可能反复处理同一组行或漏掉某些行 -
READPAST不提供一致性保证：你看到的“可更新行”可能在你真正UPDATE前已被别人改掉（需要业务层处理重复或冲突）
替代方案对比：NOLOCK vs READPAST vs UPDLOCK
NOLOCK 虽然也能跳过锁，但会读到未提交数据（脏读），不适合做更新依据；READPAST 至少保证读到的是已提交行（只是跳过被锁的）。如果目标是“只更新当前没人动的行”，READPAST 更安全。
但若想主动抢占某行更新权，应考虑 UPDLOCK + ROWLOCK 组合，在 SELECT 阶段就加更新锁，避免后续 UPDATE 时冲突。不过这又回到阻塞逻辑，和 READPAST 的“跳过”哲学相反。
真正难处理的是：当业务要求“必须处理这批数据，不能跳过”，那 READPAST 就不该用——它本质是妥协方案，不是并发控制方案。用之前得确认跳过是否可接受，以及跳过的行是否会在下次轮询中被补上。
