使用Entity Framework查询记录数出现高读取量该如何优化？

性能差异核心原因 #

你观察到的EF生成SQL和手写SQL逻辑等价但性能差异巨大，核心是执行计划选择差异导致的：手写SQL是即席查询，SQL Server会针对masterId=1的常量生成专属最优执行计划；EF生成的是参数化查询，可能复用了针对其他参数值生成的低效执行计划（参数嗅探问题），也可能是LINQ写法引导优化器选错了索引。

可行优化方案 #

• 调整LINQ查询写法，从父表驱动查询
  不要从子表导航父表字段，改为先过滤父表再关联子表统计，更贴合你手写SQL的逻辑，更容易触发正确的索引选择：

  var count = db.ParentTable
      .Where(p => p.masterId == 1)
      .SelectMany(p => p.ChildTable)
      .Where(c => !c.isActive)
      .Count();
  

• 直接执行已优化的手写SQL（最可控，性能最优）
  既然你已经验证过手写T-SQL的性能，直接通过EF的原生查询接口执行即可，无额外开销，性能和手动执行完全一致：

  var count = db.Database.SqlQuery<int>(@"
      SELECT COUNT(1) 
      FROM ParentTable 
      JOIN ChildTable ON ParentTable.id = ChildTable.id
      WHERE masterId = @masterId AND isActive = 0", 
      new System.Data.SqlClient.SqlParameter("@masterId", 1)).Single();
  

• 补充覆盖索引
  不管用哪种写法，建立以下两个覆盖索引后，所有等价查询都能走索引覆盖，逻辑读会降到最低：

  • 父表索引：CREATE NONCLUSTERED INDEX IX_ParentTable_MasterId ON ParentTable(masterId) INCLUDE (id)
  • 子表索引：CREATE NONCLUSTERED INDEX IX_ChildTable_Id ON ChildTable(id) INCLUDE (isActive)

• 解决参数嗅探问题
  如果确认是参数嗅探导致执行计划选错，可以在原生SQL末尾添加OPTION(RECOMPILE)提示，强制SQL Server针对当前参数生成最优执行计划。

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