SQL Server行锁表更新阻塞问题：是否必须为WHERE条件字段加索引？

阻塞根本原因 #

你遇到的无匹配更新行仍阻塞的核心逻辑是：SQL Server执行更新语句时，如果执行计划走全表/聚簇索引扫描时，会先对扫描到的每一行申请更新锁（U锁），再判断该行是否符合WHERE条件。哪怕该行不满足更新条件，也会等待该行上已存在的排他锁/更新锁释放，所以即使没有待更新记录也会被之前锁定的无关行卡住。

是否必须给WHERE条件涉及的字段加索引 #

是的，这类高并发写场景下，给WHERE过滤、关联条件涉及的字段加合适的索引是最优解决方案，核心目的是让SQL Server生成索引查找的执行计划，只会定位到符合条件的行再加锁，不需要扫描无关行，自然不会碰到你之前锁定的无关记录，不会触发阻塞。
你第一条更新语句UPDATE PATIENT SET PA_CYCLE=3 WHERE PA_CYCLE=1加了PA_CYCLE单列索引后不再阻塞，就是因为优化器可以直接走PA_CYCLE的索引查找，发现没有PA_CYCLE=1的匹配行就直接返回，不需要扫描全表。

最后一条更新语句的解决方案 #

你只给PA_CYCLE加单列索引后仍然阻塞，是因为该更新语句的关联逻辑还用到了PA_CLINIC字段，单列索引无法覆盖查询需求，优化器要么需要回表访问聚簇索引获取PA_CLINIC的值，回表过程中还是会扫描到被锁定的行；要么优化器判断回表成本过高，直接选择全表扫描，同样会触发阻塞。可以按以下步骤处理：

• 给PATIENT表创建覆盖过滤、关联需求的复合索引：

CREATE NONCLUSTERED INDEX IX_PATIENT_PA_CYCLE_PA_CLINIC ON PATIENT (PA_CYCLE, PA_CLINIC);

该索引包含了UPDATE语句中用到的PATIENT表所有条件字段，优化器可以直接通过该索引判断是否存在符合PA_CYCLE=1的行，不需要回表访问聚簇索引，自然不会碰到被锁定的记录。

• 给UTILITY表创建覆盖子查询需求的复合索引，进一步优化执行计划：

CREATE NONCLUSTERED INDEX IX_UTILITY_UT_KEY_UT_PATIENT ON UTILITY (UT_KEY, UT_PATIENT);

这样EXISTS子查询可以直接通过该索引完成关联判断，不需要扫描全表，也能避免优化器选择嵌套循环连接时触发全表扫描PATIENT表的情况。

• 可选方案：如果业务允许，可以开启数据库的读提交快照隔离级别（RCSI），此时更新操作的读阶段不会申请U锁，不会因为行锁产生等待，该方案不需要修改索引，但需要提前评估业务对数据一致性的要求。

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