固定800GB大小TempDB下超大表MERGE因空间报错，是否为MERGE机制限制

报错并非MERGE语句的固有机制导致必须将整张目标表加载到TempDB，问题根源是优化器选择的执行路径触发了超大规模排序操作，耗尽了全部TempDB预留空间。

报错触发逻辑拆解 #

你遇到的Could not allocate space for object 'dbo.SORT temporary run storage'错误，直接对应执行计划中的排序算子落盘开销，常见诱因如下：

• 连接条件索引缺失或统计信息失效：MERGE的匹配逻辑为src.JoinFields = targ.JoinFields，如果目标表TableName的JoinFields上没有适配的覆盖索引（比如仅存在聚集索引但字段不匹配、索引碎片化严重、统计信息过时），优化器为了完成源、目标两侧的关联匹配，会选择对全量目标表按连接键排序的执行路径，此时排序对象是整张TB级主表，800GB的TempDB预留空间完全无法承载。
• 执行路径选择偏差：如果优化器错误预估源数据规模（实际源数据为80-100GB，若统计信息偏差导致预估行数远高于实际值），会优先选择合并连接、哈希连接这类需要两侧数据预排序或全量载入内存的执行路径，进一步放大TempDB的落盘需求。
• 附加逻辑的额外开销：OUTPUT子句写入表变量、更新字段无覆盖索引等问题，也会触发额外的排序落盘操作，叠加TempDB占用峰值。

优化方案 #

无需直接弃用MERGE逻辑，可按优先级调整处理：

• 先校验目标表索引：确保目标表的JoinFields上存在覆盖连接匹配条件、UPDATE涉及字段的非聚集索引，先单独运行MERGE的USING子句查询，核对执行计划的预估行数与实际80-100GB的源规模是否匹配。
• 强制指定嵌套循环执行路径：若确认源数据量远小于目标表规模，可在MERGE语句末尾追加OPTION (LOOP JOIN)提示，让优化器走「小源表探测目标索引」的嵌套循环路径，完全避免大规模排序落盘。
• 拆分任务分批执行：若源数据集本身规模仍过大，可按UpdateDateTime或连接键的区间拆分源数据，分批执行MERGE逻辑，将单批数据规模控制在数GB级别，降低单次执行的TempDB峰值和事务大小。
• 临时调整TempDB配置：若暂无法修改业务逻辑，可临时开启TempDB的自动增长属性，或追加额外的TempDB数据文件，避免空间不足直接中断执行。

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