EF Core与SSMS执行同一参数化查询性能差异过大问题排查

1. 性能差异的核心原因 #

最常见的原因是参数嗅探（Parameter Sniffing）：SQL Server会缓存首次执行查询时基于特定参数生成的执行计划，后续执行若使用不同参数，可能复用不匹配的计划（比如首次用小参数生成了适合小数据集的嵌套循环，后续大参数仍用该计划而非更高效的哈希连接）。

其次是连接SET选项不一致：EF Core与SSMS默认的数据库连接配置（如ARITHABORT、ANSI_NULLS等）不同，SQL Server会将这些选项作为执行计划缓存的标识，不同配置会触发不同的计划生成，部分选项还会直接影响优化器对索引、连接方式的选择。

另外可能存在隐性参数类型差异：EF Core生成的参数可能与SSMS手动输入的参数类型/精度不一致（比如字符串参数长度、数值精度不同），导致优化器选择不同的索引或执行逻辑。

2. 影响执行计划选择的连接选项 #

确实存在多个关键连接选项会影响执行计划，核心包括：

• ARITHABORT：SSMS默认开启（ON），EF Core默认关闭（OFF）。当该选项为OFF时，SQL Server可能无法使用计算列索引，或生成更保守的执行计划，导致性能下降。
• ANSI_NULLS、QUOTED_IDENTIFIER：这两个选项是执行计划缓存的必要匹配项，若前后连接的配置不一致，会触发全新的计划生成；同时它们会影响优化器对谓词条件的解析逻辑。
• ANSI_WARNINGS、CONCAT_NULL_YIELDS_NULL：这些选项改变数据处理的行为逻辑，会影响优化器对查询成本的估算，进而影响计划选择。
• 此外，连接的默认数据库、登录账号的上下文（如默认架构）也可能间接影响执行计划的生成。

3. 深入排查的步骤 #

• 对比执行计划：
  • 在SSMS中执行查询并查看「实际执行计划」；
  • 在EF Core执行前，通过SET SHOWPLAN_XML ON或SQL Server Profiler捕获Showplan XML事件，获取EF Core对应的执行计划；
  • 对比两个计划的索引使用、连接方式、行数估算值，定位差异点。
• 校验SET选项一致性：
  • 分别在EF Core连接会话和SSMS中执行DBCC USEROPTIONS，输出所有当前生效的SET选项，逐一对比差异，重点关注ARITHABORT、ANSI_NULLS等关键项。
• 验证参数嗅探问题：
  • 在EF Core的查询中添加OPTION (RECOMPILE)，强制每次执行重新生成计划，若性能与SSMS一致，则确认是参数嗅探导致；
  • 也可尝试OPTION (OPTIMIZE FOR (@param = '目标参数值'))，指定优化器针对特定参数值生成计划，验证效果。
• 检查参数类型匹配度：
  • 用SQL Server Profiler捕获EF Core生成的完整参数化SQL，对比SSMS中手动执行的参数定义（如字符串长度、数据类型），确认是否存在隐性差异。
• 更新统计信息：
  • 执行UPDATE STATISTICS [目标表名]，更新表的统计数据，过期的统计信息会导致优化器生成错误的执行计划。
• 利用Query Store分析：
  • 若数据库开启了Query Store，可查看该查询的所有执行计划，对比不同计划的执行时长、逻辑读等指标，定位EF Core使用的低效计划及其触发原因。

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