Entity Framework调用存储过程性能远低于SSMS直接执行原因排查

导致该性能差异的核心原因如下： #

• 连接级SET选项不同，执行计划无法共享
  SQL Server的执行计划缓存和连接的SET选项强绑定，只要SET配置有差异，即使执行完全相同的SQL语句，也会被判定为不同的执行上下文，生成、使用不同的执行计划。SSMS默认开启SET ARITHABORT ON，而Entity Framework的数据库连接默认该选项为OFF，如果你EF对应的执行计划是之前适配其他参数值生成的（即参数嗅探问题），就会出现执行效率远低于SSMS的情况。
  你可以通过如下SQL查询当前的存储过程执行计划缓存：

SELECT plan_handle, usecounts, set_options, text 
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
WHERE text LIKE '%MySproc%'

如果查询结果中出现两条set_options值不同、对应SQL文本均为存储过程调用的缓存项，即可确认是该问题导致。

• 参数类型映射不匹配，触发隐式类型转换
  SQL Server Profiler中展示的EXEC [dbo].[MySproc] @id=10只是格式化后的文本结果，实际EF传递的参数数据类型可能和存储过程定义的参数类型不一致。例如存储过程中@id定义为int，但EF自动映射的参数类型为bigint或nvarchar，执行时会触发表字段的隐式类型转换，导致索引无法命中，逻辑读大幅升高。
  你可以在Profiler中跟踪「RPC:Starting」事件，查看@id参数的实际类型定义，和存储过程的参数定义做比对即可确认。

• 隐式事务带来的额外读取开销
  EF默认会对未显式包裹事务的存储过程调用隐式开启事务，部分场景下会导致SQL Server需要额外读取版本存储、处理加锁逻辑，也会推高逻辑读数值。你可以对比两次执行的事务上下文配置排查该问题。

推荐排查解决方法： #

1. 统一EF和SSMS的连接SET选项，在EF上下文初始化时执行SET ARITHABORT ON
2. 显式指定EF调用存储过程的参数类型，避免隐式转换
3. 对存储过程调用添加OPTION (RECOMPILE)调试，确认是否为参数嗅探导致的执行计划问题
4. 必要时使用EXEC sp_recompile N'dbo.MySproc'清除存储过程的旧缓存执行计划

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