sql server 2022中update子查询仍存在锁扩散问题，应优先使用join写法；若必须用子查询，需通过索引提示、top限流、recompile及分批处理（如表变量）严格控锁范围。
UPDATE子查询在SQL Server 2022中仍会锁扩散，优先换JOIN
SQL Server 2022 并未改变 UPDATE ... WHERE id IN (SELECT ...) 的锁行为：它仍可能对子查询扫描的**全部匹配行**（哪怕最终没更新）加意向锁，且当扫描行数超过5000时极易触发锁升级为表锁。这不是bug，是引擎为减少锁管理开销做的默认权衡。
真正可控的写法是用 UPDATE ... FROM ... JOIN 显式声明驱动表和关联逻辑：
UPDATE o SET o.status = l.status FROM orders o INNER JOIN order_logs l ON o.order_id = l.order_id WHERE l.created_at > '2024-01-01';
- 必须确保
order_logs.created_at有索引，否则 JOIN 仍会全表扫描并锁住所有行 - 如果
order_logs中一个order_id多次出现，UPDATE行为不确定——加GROUP BY或DISTINCT子查询预处理 - SQL Server 2022 的新特性（如批处理模式执行计划）对这种写法有自动优化，但对
IN子查询无额外加持
非换JOIN不可时，如何给子查询“收边”
某些场景（比如子查询含 ROW_NUMBER() 分页、跨库链接或聚合）无法直接改写为 JOIN，那就必须主动约束子查询的执行路径，否则锁范围完全失控。
- 强制走索引：
SELECT order_id FROM order_logs WITH (INDEX(idx_created_at)) WHERE created_at > '2024-01-01'，避免优化器误选全表扫描 - 显式限流：
SELECT TOP(5000) order_id FROM order_logs WHERE created_at > '2024-01-01' ORDER BY order_id，配合外层循环分批，防止单次子查询返回过多ID - 禁用参数嗅探干扰：
OPTION (RECOMPILE)加在子查询后，避免因历史参数导致执行计划错配
分批更新比单次子查询更稳，别迷信“一条SQL搞定”
即便用了 TOP 和 ORDER BY，UPDATE ... WHERE id IN (SELECT TOP(n) ...) 在 SQL Server 2022 中仍是高风险写法：子查询结果集可能被缓存在 tempdb，锁持续时间与结果集大小正相关，且无法控制每批实际更新行数。
推荐两步走：
DECLARE @batch_ids TABLE (id INT PRIMARY KEY); WHILE (1=1) BEGIN INSERT INTO @batch_ids SELECT TOP(2000) id FROM orders WHERE status = 'pending' ORDER BY id; IF @@ROWCOUNT = 0 BREAK; UPDATE o SET o.status = 'shipped' FROM orders o INNER JOIN @batch_ids b ON o.id = b.id; DELETE FROM @batch_ids; END;
-
@batch_ids是内存表，不走 tempdb，锁只集中在当前批次的主键上 - 每次
UPDATE后立刻清空表变量，避免残留数据影响下轮 - 若需监控进度，可在循环内加
RAISERROR('Updated %d rows', 0, 1, @@ROWCOUNT) WITH NOWAIT;
别忽略隔离级别和版本存储的隐性成本
即使你把语句写得再干净，如果数据库启用了 READ_COMMITTED_SNAPSHOT，大量并发更新仍可能压垮 tempdb 的版本存储区——这不是锁问题，但会导致 UPDATE 变慢甚至超时。
- 查当前设置：
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME(); - 若为
1且tempdb压力大，考虑临时关闭（需SINGLE_USER模式）或扩容tempdb数据文件 - 用
NOLOCK查子查询？不行——UPDATE本身仍要加排他锁，NOLOCK对写操作无意义，还可能让子查询读到脏数据导致误更新
