update关联大表时cpu飙升的直接原因是hash join构建哈希表过程极度消耗cpu，尤其右表千万级且无过滤时，cpu时间占比可达90%以上；根本在于缺少满足三条件的索引策略（选择性where索引、精简连接列索引、最新统计信息），叠加参数嗅探与并行度失控。
Update关联大表时CPU飙升的直接原因
不是UPDATE语句本身慢，而是SQL Server在执行UPDATE ... FROM或UPDATE t1 SET ... FROM t1 JOIN t2这类写法时，如果缺少合适索引，优化器大概率选择Hash Join——而Hash Join在构建哈希表阶段会把右表（通常是被关联的大表）全量读入内存、逐行计算哈希值、分配桶、处理冲突。这个过程极度消耗CPU，尤其当右表是千万级且无过滤条件时，cpu_time可能占整个语句耗时的90%以上。
为什么Hash Join比Nested Loops更易触发CPU飙升
常见误区是“加了索引就一定走Nested Loops”，但实际取决于：左表输出行数预估、右表是否可寻址、统计信息是否准确。当优化器预估左表结果集较大（比如UPDATE匹配了上百万行），即使右表有索引，它仍可能放弃Seek+Loop，转而用Hash——因为Hash的渐近复杂度是O(n+m)，而Loop最坏是O(n×m)。但现实是：n=100万、m=5000万时，Hash建表的CPU密集计算远超Loop的多次索引Seek。
-
Hash Join：CPU集中在哈希计算、内存重分配、溢出到tempdb（若内存不足） -
Nested Loops：CPU分散在多次Index Seek和键查找，单次开销小，总体更平稳 - 关键判断依据：
EXPLAIN中看PhysicalOp是否为Hash Match，并检查EstimateRows是否严重偏离真实值
UPDATE关联场景下真正有效的索引策略
不是“给关联字段加索引”就完事。必须同时满足三个条件才能让优化器倾向Nested Loops：
- 被更新表（t1）的关联列上要有
WHERE条件对应的选择性索引（例如UPDATE t1 SET x=... FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t1.status = 'PENDING'，则需(status, id)复合索引） - 被关联表（t2）的连接列（如
t2.t1_id）必须有索引，且该索引的KEY部分**仅包含连接列**（避免宽索引拖慢Seek） - 两表统计信息必须最新：
UPDATE STATISTICS t1 WITH FULLSCAN、UPDATE STATISTICS t2 WITH FULLSCAN，否则优化器会低估/高估行数，强行选Hash
反例：CREATE INDEX IX_t2_t1id ON t2(t1_id, created_time, amount)看起来合理，但因包含非连接列，可能导致Seek后仍需Key Lookup，优化器权衡后仍弃用。
容易被忽略的隐性陷阱：参数嗅探 + 并行度
即使索引和统计信息都正确，以下两点仍会导致CPU毛刺反复出现：
- 参数化UPDATE语句（如存储过程中
UPDATE t1 SET ... FROM t1 JOIN t2 ON t1.id = @id）遇到@id首次传入一个高选择性值（返回1行），生成计划缓存；后续传入低选择性值（返回100万行）时复用旧计划，强制走Loop导致大量Seek，CPU持续高位——这不是Hash问题，而是参数嗅探失控 -
max degree of parallelism未设置，SQL Server对大关联UPDATE自动启用全部CPU核，Hash Join并行线程间同步等待（CXPACKET）加剧CPU争抢，监控中可见单个逻辑处理器100%、其余空闲
验证方法：查sys.dm_exec_requests中该UPDATE的degree_of_parallelism值；若>1且wait_type频繁出现CXPACKET，立刻执行sp_configure 'max degree of parallelism', 4并RECONFIGURE。这比调优索引见效更快。
