ROWLOCK只是提示而非强制行锁，实际锁粒度取决于执行计划、索引和隔离级别；未走索引时易退化为页锁或表锁，需配合UPDLOCK+有效索引才能确保行级更新安全。
ROWLOCK 不能“强制”行级更新，它只提示、不保证
SQL Server 中的 ROWLOCK 是一个**表提示（table hint）**，不是指令。它告诉优化器“尽量用行锁”，但最终是否真用行锁，取决于执行计划、索引结构、数据分布和当前隔离级别。尤其在 UPDATE 语句中，若无法走索引 SEEK（比如 WHERE 条件没命中索引、或索引不覆盖过滤列），SQL Server 很可能退化为扫描 + 页锁，ROWLOCK 提示会被忽略。
常见错误现象：
— 执行 UPDATE Orders WITH (ROWLOCK) SET Status = 'Shipped' WHERE OrderID = 12345 后，查 sys.dm_tran_locks 发现 resource_type 是 PAGE 或甚至 TAB；
— 同一语句在不同数据量下锁粒度不一致，小表生效，大表失效。
- 必须配合有效索引：WHERE 列要有单列索引或复合索引的前导列，否则 SQL Server 无法定位到具体行，自然无法加行锁
- 避免在高并发批量更新中硬加
ROWLOCK：它会增加锁管理开销，反而更容易触发锁升级（见下一条） -
ROWLOCK单独使用对 UPDATE 几乎无意义；真正起作用的是与UPDLOCK或HOLDLOCK组合，用于控制读-改之间的锁生命周期
UPDATE 场景下真正有效的 ROWLOCK 组合是 UPDLOCK + ROWLOCK
单纯 WITH (ROWLOCK) 在 UPDATE 中既不改变锁类型（UPDATE 默认就尝试加 X 锁），也不延长锁持有时间。而 UPDLOCK 的作用是：在读取阶段就加 U 锁（更新锁），防止其他事务同时读同一行再抢着更新，从而规避死锁；加上 ROWLOCK 则是进一步限定 U 锁的粒度为行级（前提是能定位到行）。
典型安全写法：
UPDATE Orders WITH (ROWLOCK, UPDLOCK) SET Status = 'Processing' WHERE OrderID = @id AND Status = 'Pending';
- WHERE 中包含状态过滤，能大幅缩小扫描范围，提高行锁命中率
-
UPDLOCK确保读取时就锁定目标行，避免“先读后锁”窗口期 - 若该语句在显式事务中，且后续还有逻辑判断（如库存校验），
HOLDLOCK可替代UPDLOCK以保持锁到事务结束 - 注意：
UPDLOCK和ROWLOCK必须用逗号分隔，且必须包裹在WITH ()中；省略WITH关键字是过时用法，未来版本将移除
为什么批量 UPDATE 加 ROWLOCK 反而更易锁升级
多维聚合查询里提过：SQL Server 默认锁升级阈值是 5000 个行锁或页锁。批量 UPDATE 若没走索引，就会全表扫描并为每行申请行锁——ROWLOCK 提示会加速触达这个阈值，系统直接升级为表锁（TAB），阻塞所有其他操作。
例如：
UPDATE Orders WITH (ROWLOCK) SET Discount = 0.1 WHERE YEAR(OrderDate) = 2025;
即使只影响 1 万行，也极可能升级。因为 YEAR(OrderDate) 无法使用普通索引（函数导致索引失效），只能扫描。
- 验证方式：执行后立即查
sys.dm_tran_locks，看resource_type是否为TAB，以及request_mode是否为X - 正确解法不是加提示，而是建计算列索引：
ALTER TABLE Orders ADD OrderYear AS YEAR(OrderDate) PERSISTED，再在OrderYear上建索引 - 若必须按时间范围更新，优先用日期范围而非函数：
WHERE OrderDate >= '2025-01-01' AND OrderDate
ROWLOCK 在 SELECT 中只有和 UPDLOCK/HOLDLOCK 搭配才有实际意义
很多人误以为 SELECT ... WITH (ROWLOCK) 能“提前锁定行供后续 UPDATE 用”，这是错的。默认 READ COMMITTED 隔离下，SELECT 的共享锁（S 锁）在语句结束后立刻释放，根本留不到 UPDATE 阶段。
真正可控的做法是：
BEGIN TRAN; SELECT * FROM Orders WITH (ROWLOCK, UPDLOCK) WHERE OrderID = 12345; -- 此时行已被 U 锁持有，其他事务无法更新或加 U/X 锁 UPDATE Orders SET Status = 'Shipped' WHERE OrderID = 12345; COMMIT;
-
UPDLOCK让 SELECT 阶段就持 U 锁，UPDATE 时直接升级为 X 锁，无需等待 -
HOLDLOCK（等价于SERIALIZABLE）可延长 S 锁到事务结束，但代价是范围锁，可能锁住间隙，慎用 - 单独
WITH (ROWLOCK)的 SELECT，在绝大多数场景下和不加提示完全一样，执行计划里看不到区别
最容易被忽略的一点：锁行为高度依赖统计信息新鲜度和参数嗅探。同一语句，第一次执行用缓存计划可能走索引（行锁），第二次因参数不同走扫描（页锁），你却以为提示“失效”了——其实是执行计划变了。
