如何提升SQL Server中批量更新查询的性能？

核心结论：你的测试结果符合常规场景 #

从你给出的测试数据来看，常规UPDATE在仅需更新匹配行的场景下性能优于MERGE——101行数据时常规UPDATE耗时15ms，MERGE耗时62ms，这是因为MERGE语句的逻辑更复杂，它需要同时处理匹配、插入、删除等多种分支逻辑，即使你只用到更新分支，SQL Server的查询优化器也会额外做分支判断的开销，在小数据集或单一更新场景下反而不如针对性的UPDATE高效。

加速批量更新的最佳实践 #

1. 确保更新条件列存在高效索引 #

• 针对UPDATE语句WHERE子句中的关联列（比如匹配更新行的主键或唯一键）创建非聚集索引或聚集索引，避免全表扫描。
• 如果更新涉及多表关联，确保所有关联列都有索引，减少表连接的开销。

2. 分批处理大型数据集 #

当更新行数超过1万行时，不要一次性执行全量更新，改用分批更新的方式，避免长时间锁表和事务日志暴涨：

DECLARE @BatchSize INT = 1000;
DECLARE @RowCount INT = @BatchSize;

WHILE @RowCount = @BatchSize
BEGIN
    UPDATE TOP(@BatchSize) t
    SET t.Column1 = s.Column1, t.Column2 = s.Column2
    FROM TargetTable t
    JOIN SourceTable s ON t.ID = s.ID
    WHERE t.IsUpdated = 0; -- 假设存在未更新标记列
    
    SET @RowCount = @@ROWCOUNT;
END

3. 利用临时表预处理数据 #

如果更新的源数据来自外部或复杂查询，先将源数据导入临时表并建立索引，再执行更新：

-- 导入源数据到临时表并创建索引
SELECT ID, Column1, Column2 INTO #TempSource FROM SourceTable WHERE [过滤条件];
CREATE CLUSTERED INDEX IX_TempSource_ID ON #TempSource(ID);

-- 基于临时表执行更新
UPDATE t
SET t.Column1 = s.Column1, t.Column2 = s.Column2
FROM TargetTable t
JOIN #TempSource s ON t.ID = s.ID;

DROP TABLE #TempSource;

4. 合理配置事务日志与恢复模式 #

• 批量更新操作前，可临时将数据库恢复模式改为简单模式，减少事务日志写入开销（操作完成后记得改回原模式）。
• 确保事务日志文件有足够空间，避免自动扩容带来的性能损耗。

5. MERGE的适用场景 #

MERGE并非完全不适合更新，它的优势在于同时需要执行更新、插入、删除中的多种操作，比如同步源表和目标表数据（存在则更新，不存在则插入，已删除则标记），此时用MERGE可以减少多次语句执行的开销，在这种复杂场景下性能才会优于单独执行UPDATE+INSERT+DELETE。

补充测试建议 #

如果你的测试数据集较小（仅101行），建议用更大的数据集（比如10万行）重新测试，观察两种语句的性能差异变化——当数据量达到一定规模，MERGE的分支逻辑开销占比会降低，但单一更新场景下UPDATE仍大概率保持优势。

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