Entity Framework已开启ARITHABORT ON但查询远慢于SSMS如何优化

根因判断 #

你遇到的是典型的SQL执行本身无性能问题，但.NET端数据库交互链路耗时过高的场景，耗时几乎都消耗在SQL执行之外的环节，可按以下优先级排查修复：

解决方案 #

• 优先验证连接加密配置（90%以上此类问题的诱因）
  你使用的.NET 5对应的Microsoft.Data.SqlClient驱动从2.0版本开始默认将Encrypt参数设为true，如果你的SQL Server未配置受信任的SSL证书，客户端会花费数百毫秒做证书验证，验证失败回退时会产生额外耗时，直接修改连接字符串添加以下两个参数即可：

Encrypt=false;TrustServerCertificate=true

修改后重新测试，多数场景下耗时会直接降到和SSMS一致的水平。

• 修正计时方式，定位具体耗时环节
  DateTime.Now的精度只有10~15ms，无法准确统计短耗时操作，建议改用Stopwatch做计时，同时将conn.Open()也纳入统计范围，确认耗时是在连接建立阶段还是SQL执行阶段：

var sw = Stopwatch.StartNew();
conn.Open();
var openCost = sw.ElapsedMilliseconds;
var rd = cmd.ExecuteReader();
sw.Stop();
var executeCost = sw.ElapsedMilliseconds - openCost;
Console.WriteLine($"连接建立耗时：{openCost}ms，查询执行耗时：{executeCost}ms");

如果耗时集中在conn.Open()，说明问题出在连接建立链路，可继续往下排查。

• 优化连接池冷启动开销
  首次调用的2.3s基本都是连接池初始化、EF模型编译的冷启动开销，可在应用启动时增加预热逻辑：主动打开一次数据库连接并执行一条简单SQL（比如SELECT 1），提前完成连接池初始化、EF模型编译。
  确认连接字符串中没有禁用连接池（默认是开启的，不要加Pooling=false参数）。

• 优化网络连接协议
  确认代码和SSMS使用的连接协议一致，可在连接字符串中强制指定使用TCP/IP协议，避免命名管道的额外开销：

Network Library=DBMSSOCN;

• EF Core额外优化
  如果后续仍使用EF Core做查询，可开启预编译模型进一步降低首次查询开销：在DbContext的OnConfiguring方法中添加：

optionsBuilder.UseModel(CompiledModels.MyDbContextModel.Instance);

再通过工具预生成上下文的编译模型即可。

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