.NET与SSMS执行SQL时执行计划并行机制差异问题咨询

AI 小北

2026-8-27

核心原因

SQL Server对不同会话提交的同逻辑查询生成不同执行计划（包括是否启用并行），本质是会话上下文、提交文本、优化器输入条件存在差异，和客户端类型无直接关联，.NET程序与SSMS的常见差异点如下：

默认SET选项不匹配：这是最高发的原因。SSMS建立连接时默认开启ARITHABORT、ANSI_NULLS、QUOTED_IDENTIFIER、ANSI_WARNINGS等选项，而部分版本的Microsoft.Data.SqlClient默认建立连接时ARITHABORT为关闭状态。SQL Server会将SET选项作为计划缓存键的一部分，不同SET选项的会话不会复用彼此的缓存计划；在数据库兼容级别低于130（SQL Server 2016）时，ARITHABORT OFF会直接导致查询优化器优先选择串行执行计划，不触发并行运算符。
会话级MAXDOP配置差异：如果程序代码中存在SET MAXDOP 1的语句、连接字符串配置了错误的MAXDOP值、连接池中的连接被之前的执行逻辑污染遗留了MAXDOP 1的配置，会强制当前会话所有查询走串行执行。
查询文本与参数定义不一致：.NET程序通过参数化查询提交请求时，如果参数的类型、长度、精度和SSMS中执行的查询定义不匹配（比如程序传nvarchar(10)类型参数，对应字段是varchar(50)，或者字符串参数长度设置远小于字段实际长度），会触发隐式转换，导致优化器估算的返回行数严重偏差，最终估算的查询执行成本低于实例配置的并行成本阈值（默认值为5），因此不会选择并行计划。
参数嗅探偏差：两边执行查询时传入的参数值不同，或者计划缓存中存储的是之前小数据量参数生成的串行计划，.NET程序连接时复用了该缓存计划，而SSMS执行时触发了重编译，基于当前参数生成了并行计划。

排查步骤

对比两边会话的SET选项：分别在.NET程序的连接会话和SSMS会话中执行DBCC USEROPTIONS，逐行对比返回的所有配置项的值，重点核对ARITHABORT、ANSI_NULLS、QUOTED_IDENTIFIER、ANSI_WARNINGS、CONCAT_NULL_YIELDS_NULL这几个直接影响计划生成的选项，任何一个值不一致都会触发独立编译。

核对会话级并行配置：分别在两个会话中执行以下语句，确认MAXDOP配置：

-- 查看当前会话的MAXDOP设置
SELECT dop FROM sys.dm_exec_sessions WHERE session_id = @@SPID;
-- 查看实例级并行成本阈值
SELECT value FROM sys.configurations WHERE name = 'cost threshold for parallelism';
-- 查看是否开启了影响并行的跟踪标记
DBCC TRACESTATUS(-1);

如果当前会话dop值为1，会强制所有查询走串行。

抓取两边实际提交的SQL内容：通过扩展事件或SQL Trace抓取.NET程序侧发往数据库的完整SQL文本、参数类型、参数长度、参数值，和SSMS中执行的内容逐字对比，重点排查是否存在隐式转换、多余的会话配置语句、事务隔离级别差异。
对比执行计划的成本评估：分别抓取两边的实际执行计划，查看.NET侧串行计划的总估算成本，如果数值低于实例配置的并行成本阈值，说明优化器判断该查询走串行成本更低，本质是行数评估存在偏差。
排查连接池污染：检查业务代码中是否存在临时修改会话级配置（比如设置MAXDOP、调整隔离级别）后未重置就释放连接的逻辑，这类问题会导致从连接池复用该连接的所有请求都继承错误配置。

解决方案

统一会话SET配置：在程序侧连接初始化逻辑中，统一配置和SSMS一致的SET选项，可在连接建立后执行标准SET语句，或通过连接字符串配置对应选项，保证ARITHABORT ON、ANSI_NULLS ON、QUOTED_IDENTIFIER ON、ANSI_WARNINGS ON、CONCAT_NULL_YIELDS_NULL ON，从根源避免SET选项不匹配导致的计划差异。
规范参数传递：编写参数化查询时，严格匹配数据库字段的类型、长度、精度，避免隐式转换；如果存在稳定的参数嗅探问题，可针对特定查询添加OPTION (OPTIMIZE FOR UNKNOWN) 提示，或对执行频率低、数据量波动大的查询添加OPTION (RECOMPILE)，保证计划符合当前参数的数据分布。
修复连接池污染问题：禁止在业务代码中随意修改会话级全局配置，如果确实需要临时调整配置，执行完逻辑后必须显式重置；同时确认连接字符串中Connection Reset配置为开启状态，保证连接从连接池取出时自动重置所有会话级配置，避免遗留设置影响后续请求。
修正并行相关配置：如果确认查询实际执行成本远高于并行成本阈值，但优化器始终低估成本，可适当调低实例级的cost threshold for parallelism值，或针对特定慢查询添加查询提示OPTION (MAXDOP 0, USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'))，引导优化器选择并行计划，禁止全局滥用查询提示。
维护统计信息：定期对大表更新统计信息，存在统计信息过期导致的行数评估偏差时，执行UPDATE STATISTICS [对应表名] WITH FULLSCAN 修正统计信息，保证优化器成本评估的准确性。

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