大容量单行INSERT脚本在单台SQL Server运行极慢问题排查

核心原因是测试环境开启了SQL Server强制参数化（Forced Parameterization），开发/生产环境使用默认简单参数化模式，这个配置不在你之前核对的CPU、内存、MAXDOP、开销阈值范围内，完全匹配你观测到的所有现象：

• 耗时和脚本体积正相关：强制参数化会扫描批处理内所有语句的字面值，把INSERT语句里的数字、字符串、日期全部替换为参数定义。按单条INSERT8个字段算，17000条语句会生成13万+参数元数据，解析器处理这些参数时都是短周期CPU操作，每个操作跑完时间片就主动让出调度器，直接触发大量SOS_SCHEDULER_YIELD等待。因为单个操作耗时极短，所以整体CPU使用率看起来远低于100%，但调度轮转的等待把总耗时拉长了几十倍。
• DROP执行完后1.8秒才启动CREATE：SQL Server处理大批次是边解析边执行，DROP作为批次第一个语句优先解析执行，执行完后解析器继续处理后续大段脚本的参数扫描，直到解析到CREATE语句位置才会触发执行事件，中间的等待全是参数解析开销。
• 注释掉后续所有语句、只保留前10条INSERT，大脚本依然慢：无论后续语句是否加了注释，整个批处理的文本都会先走词法扫描和参数化流程，35000行脚本里的所有字面值都会被遍历处理，哪怕后面的语句根本不执行，这部分扫描开销完全不会减少，和你测到的1859ms CPU时间完全吻合。
• 换临时表/持久化表、换执行数据库都不影响速度：强制参数化是实例/数据库级的解析层行为，和数据写入目标、执行所在数据库无关，只要SQL语句进入解析流程就会触发。

直接在测试环境执行脚本前先运行下面的语句，再重跑插入脚本：

-- 切换到执行脚本的对应数据库，临时关闭强制参数化
ALTER DATABASE CURRENT SET PARAMETERIZATION SIMPLE;
GO

如果执行后脚本耗时降到和开发/生产一致的30秒级别，即可确认根因。

如果测试环境因为业务要求必须保留强制参数化，可选择以下任意方案绕开问题：

• 把逐行单条INSERT改写为批量插入格式，即单条INSERT语句后拼接多组VALUES值，把17000条语句压缩到10~20条，从根源减少参数解析的工作量，执行速度本身也会比逐行插入快两个数量级，是最优方案。
• 用BULK INSERT、bcp或者OPENROWSET直接导入生成的数据文件，绕开逐句解析INSERT的流程，导入速度最快。
• 给回补脚本单独创建计划指南，指定该批次使用简单参数化，不影响其他业务的强制参数化配置。

如果关闭强制参数化后问题仍然存在，按优先级排查以下未核对的配置项：

• 对比三个环境的SQL Server补丁版本（SP、CU版本），部分SQL Server 2016/2019的早期累积更新存在大批次词法解析的性能bug，升级到最新CU即可修复。
• 检查测试环境是否开启了全实例SQL审计、默认XEvent会话采集了语句级完成事件，这类全量语句采集在大批次场景下会带来额外的解析和序列化开销。
• 检查测试服务器是否安装了带流量扫描功能的终端安全软件，在TDS协议层拦截解析SQL脚本带来额外开销，把SQL Server服务和端口加入排除项即可解决。

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