为何INSERT INTO EXEC比直接在存储过程内使用INSERT INTO速度慢？

针对你遇到的800万行数据插入耗时差异，核心原因集中在SQL Server处理这两种执行方式的底层机制差异上，具体如下：

• 执行计划的整体优化能力不同
  当你在外部执行INSERT INTO TBLNAMEHERE EXEC SPNAMEHERE时，数据库会把存储过程的执行和后续的插入操作视为两个独立步骤，无法生成跨步骤的最优联合执行计划。而把插入逻辑嵌入存储过程内部时，查询优化器可以整体分析源数据查询和插入操作，生成更高效的端到端执行计划——比如让源查询的结果直接流式写入目标表，避免不必要的中间处理。

• 中间数据传递的额外开销
  外部调用时，存储过程返回的800万行结果集需要先被传递到外部会话的内存缓冲区，再从缓冲区写入目标表，相当于多了一次完整的数据拷贝流程。这种额外的内存IO和数据序列化开销，在大结果集场景下会被急剧放大。而内部执行时，结果集可以直接从源查询的执行管道写入目标表，跳过了跨会话的数据传递环节。

• 事务日志的写入策略差异
  如果数据库采用批量日志恢复模式，存储过程内部的插入操作可以利用最小化日志记录优化，大幅减少日志生成量和写入开销。但外部的INSERT INTO...EXEC可能无法触发这种优化——因为跨会话的操作会被数据库视为普通的逐行插入，强制生成完整的事务日志，导致日志写入耗时飙升。

• 统计信息的利用效率不同
  外部调用时，查询优化器无法直接获取存储过程内部查询的统计信息，可能会错误预估结果集的大小，进而选择低效的插入策略（比如使用逐行插入而非批量插入）。而内部嵌入时，优化器可以直接基于源查询的统计信息，选择最优的批量插入逻辑，提升执行效率。

• 上下文切换的额外消耗
  执行EXEC SPNAMEHERE会创建一个子执行上下文，结果集需要在子上下文和父上下文之间传递，带来频繁的上下文切换开销。而内部执行全程在同一个上下文内完成，没有这部分额外消耗。

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