update join临时表比逐条快，因sql server可将整个更新下推至单次执行计划，避免应用层反复建连、发语句、解析sql；临时表与主表join字段均需建索引，否则退化为全表扫描。
UPDATE + JOIN 临时表为什么比逐条快
因为 SQL Server 能把整个更新操作下推到执行计划里一次性完成，避免了应用层反复建连接、发语句、解析 SQL 的开销。逐条 UPDATE 在几万行时实际是几万次独立事务（哪怕没显式 BEGIN），而 UPDATE ... FROM #temp 是单次编译、单次锁资源、单次写日志。
临时表必须带索引，否则JOIN会变全表扫描
常见错误是建完 #temp 就直接 JOIN 主表，结果执行计划里出现「Nested Loops + Table Scan」——主表和临时表都扫一遍，性能反而更差。
- 临时表字段（如
id、code）必须建CLUSTERED INDEX或至少NONCLUSTERED INDEX - 主表上用于 JOIN 的字段（如
Employees.EmployeeID）也得有索引，否则即使临时表有索引也没用 - 别用表变量
@temp替代#temp：表变量默认无统计信息，优化器常误判行数，导致选错执行计划
分批控制日志和锁，但别在 JOIN 内部做
想更新 50 万行？不要把 TOP (1000) 塞进 UPDATE ... FROM #temp 里——那只会随机切前 1000 行，不是按业务顺序分片。正确做法是先对主表分片，再让每批的 ID 集合 JOIN 临时表：
- 用
WHERE id BETWEEN @start AND @end切主表范围，再 JOIN 临时表（确保临时表只含该批次需要更新的 ID） - 每批单独
BEGIN TRANSACTION+COMMIT，避免长事务拖慢其他查询 - 别依赖
OFFSET / FETCH分页：SQL Server 2012+ 支持，但OFFSET 499000 ROWS仍要跳过前 49.9 万行，IO 开销大
容易被忽略的锁与日志细节
即使用了临时表 JOIN，如果没注意隔离级别或提示，还是可能锁整张表或日志暴涨：
- 加
WITH (TABLOCK)提示可减少行锁数量，但会阻塞其他会话读写——只在维护窗口、单线程执行时用 - 更新涉及大量索引列？考虑提前
ALTER INDEX ... DISABLE，更新完REBUILD，比边更新边维护索引快 3–5 倍 - 确认数据库恢复模式：如果是
FULL，大批量更新前手动BACKUP LOG，防止事务日志撑爆磁盘
