SQL Server UPDATE语句是否支持内部并行执行？

一、UPDATE并行执行的核心规则 #

SQL Server支持并行DML操作（包括UPDATE），但触发并行需要满足多个前提：

• 数据库兼容性级别≥100（对应SQL Server 2008及以上版本）
• 实例/数据库级的MAXDOP（最大并行度）配置不为1，且服务器具备多CPU核心
• 表数据量足够大，查询优化器判断并行执行的收益高于单线程开销
• 表为堆表或带有非聚集索引的表（聚集索引表的UPDATE也可能触发并行）

二、堆表UPDATE未触发并行的常见原因 #

你用堆表却没得到并行计划，大概率是这些因素导致：

• 数据量不足：如果表行数太少，优化器会判定单线程执行更高效，不会启用并行
• 统计信息过时：SQL Server依赖统计信息评估数据规模和执行成本，过时的统计信息会让优化器误判选择单线程
• 操作成本过低：你的UPDATE只是简单的varchar转nvarchar复制（隐式转换），当列长度不大时，优化器认为单线程开销更低
• 配置限制：实例或数据库的MAXDOP被强制设为1，直接禁用并行
• 锁/阻塞干扰：表上存在其他锁或阻塞操作，会影响并行计划的生成

三、强制并行的方法（谨慎使用） #

如果确认满足前提条件仍未触发并行，可以尝试用查询提示强制，但需先测试性能：

update t 
set new_col_1 = col_1,   
    new_col_2 = col_2, 
    ..., 
    new_col_N = col_N 
OPTION (MAXDOP 4); -- 4为你期望的并行度，根据服务器核心数调整

注意：强制并行并非万能，小表或IO瓶颈场景下反而可能降低性能，必须结合实际测试验证。

四、更高效的迁移替代方案 #

比起纠结并行UPDATE，以下两种方式能大幅减少UNDO/REDO日志，提升迁移速度：

1. 分批更新 #

将全表拆分成小批次更新，避免一次性生成海量日志：

DECLARE @BatchSize INT = 10000;
DECLARE @LastKey INT = 0; -- 假设表有自增主键ID

WHILE EXISTS (SELECT 1 FROM t WHERE ID > @LastKey)
BEGIN
    UPDATE TOP (@BatchSize) t
    SET new_col_1 = col_1, new_col_2 = col_2
    WHERE ID > @LastKey;
    
    SET @LastKey = (SELECT MAX(ID) FROM t WHERE ID > @LastKey);
    WAITFOR DELAY '00:00:01'; -- 可选，缓解日志写入压力
END

2. SELECT INTO创建新表（最优推荐） #

直接创建包含nvarchar列的新表，插入数据后切换表名，这种方式日志量远低于全表UPDATE：

-- 1. 创建带nvarchar列的新表，自动完成类型转换
SELECT CAST(col_1 AS NVARCHAR(xxx)) AS col_1,
       CAST(col_2 AS NVARCHAR(xxx)) AS col_2,
       -- 其他列...
INTO t_new
FROM t;

-- 2. 还原原表的索引、约束、触发器等
CREATE CLUSTERED INDEX IX_t_new_ID ON t_new(ID);
-- 添加上原表的外键、默认值、触发器等

-- 3. 原子性切换表名
BEGIN TRANSACTION;
DROP TABLE t;
EXEC sp_rename 't_new', 't';
COMMIT TRANSACTION;

注：简单恢复模式下，SELECT INTO属于最小日志操作，日志生成量极低，迁移速度远快于全表UPDATE。

总结 #

SQL Server确实支持并行UPDATE，但触发条件严格，堆表不一定能自动启用。如果你的场景无法触发并行，优先考虑分批更新或SELECT INTO的迁移方案，这两种方法在控制日志压力和提升效率上比强制并行更可靠。

内容的提问来源于stack exchange，提问作者Edward Hayrabedian