EF Core 7查询为何偶尔出现性能骤降？

在Blazor Server应用中使用EF Core 7作为ORM，多数小型查询正常，但有一个复杂查询偶尔出现无规律的性能突降：通常执行耗时不足10ms，却会随机飙升至6000ms甚至10000ms以上。反复执行该查询，卡顿出现的频次无规律——有时5次就触发，有时需50次以上；但在SSMS中执行EF生成的SQL时，耗时始终稳定且快速。

查看执行计划，发现最大开销来自排序操作（占比11%），其余节点占比均在2%及以下，但不知如何利用该信息优化。当前处于测试阶段，多数表行数不足10条，已尝试**拆分查询（AsSplitQuery）**但无效果；因早期设计限制，必须使用实体类而非DTO/视图模型，无法通过投影优化。

问题查询代码如下：

bike = await dbContext.Bikes
                    .Include(bike => bike.FrameProfile)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration)
                            .ThenInclude(forkConfig => forkConfig.Damper)
                                .ThenInclude(forkDamper => forkDamper.CompressionTune)
                                    .ThenInclude(compressionTune => compressionTune.MappedProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration)
                            .ThenInclude(forkConfig => forkConfig.Damper)
                                .ThenInclude(forkDamper => forkDamper.ReboundTune)
                                    .ThenInclude(reboundTune => reboundTune.MappedProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration.Spring)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration.SuspensionProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration)
                            .ThenInclude(shockConfig => shockConfig.Damper)
                                .ThenInclude(shockDamper => shockDamper.CompressionTune)
                                    .ThenInclude(compressionTune => compressionTune.MappedProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration)
                            .ThenInclude(shockConfig => shockConfig.Damper)
                                .ThenInclude(shockDamper => shockDamper.ReboundTune)
                                    .ThenInclude(reboundTune => reboundTune.MappedProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration.Spring)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration.SuspensionProduct)
                    .Include(bike => bike.BikeConfigurations)
                        .ThenInclude(bikeConfig => bikeConfig.Wheels)

                    .AsSplitQuery()
                    .AsNoTracking()
                    .TagWith("Load complete Bike from database")
                    .SingleAsync(a => a.Id == id, cancellationToken);

一、针对随机卡顿的排查方向 #

• 数据库连接池问题：Blazor Server是长连接模型，若连接池耗尽或连接复用异常，会导致查询等待获取连接的时间陡增。检查数据库连接字符串的Max Pool Size配置（默认100），同时在EF Core日志中监控连接的获取/释放情况，确认是否存在连接泄漏。
• EF Core查询缓存失效：EF Core会缓存查询计划，但参数嗅探、统计信息过期等情况可能导致缓存失效，每次重新编译查询计划。可尝试强制参数化查询，或手动更新表的统计信息（执行UPDATE STATISTICS [TableName]）。
• Blazor Server线程上下文阻塞：Blazor Server使用单线程上下文处理请求，若其他请求占用线程资源，会导致该查询等待调度。通过应用性能监控工具（如PerfView）查看线程等待情况，确认是否存在线程饥饿。

二、针对排序开销的优化 #

虽然排序占比仅11%，但随机卡顿可能与排序时的内存分配/磁盘溢出有关：

• 添加合适的索引：找到执行计划中排序对应的字段，为该字段添加索引。例如，若排序针对BikeConfigurations的关联字段，可在关联外键上创建包含排序字段的索引，让数据库直接利用索引排序，避免内存排序。
• 显式指定排序逻辑：通过OrderBy显式指定排序字段，避免EF Core生成不必要的排序，或引导数据库使用更优的索引路径。

三、EF Core查询本身的优化 #

• 合并重复Include：当前代码多次重复Include(bike => bike.BikeConfigurations)，可合并为链式调用减少EF Core的解析开销：

  .Include(bike => bike.BikeConfigurations)
      .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration)
          .ThenInclude(forkConfig => forkConfig.Damper)
              .ThenInclude(forkDamper => forkDamper.CompressionTune)
                  .ThenInclude(compressionTune => compressionTune.MappedProduct)
      .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration.Damper.ReboundTune)
          .ThenInclude(reboundTune => reboundTune.MappedProduct)
      .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration.Spring)
      .ThenInclude(bikeConfig => bikeConfig.ForkConfiguration.SuspensionProduct)
      .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration)
          .ThenInclude(shockConfig => shockConfig.Damper)
              .ThenInclude(shockDamper => shockDamper.CompressionTune)
                  .ThenInclude(compressionTune => compressionTune.MappedProduct)
      .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration.Damper.ReboundTune)
          .ThenInclude(reboundTune => reboundTune.MappedProduct)
      .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration.Spring)
      .ThenInclude(bikeConfig => bikeConfig.ShockConfiguration.SuspensionProduct)
      .ThenInclude(bikeConfig => bikeConfig.Wheels)
  

  合并后EF Core会生成更简洁的查询逻辑，减少不必要的解析和SQL生成开销。
• 改用AsNoTrackingWithIdentityResolution：AsNoTracking可能导致EF Core重复创建相同实体的实例，增加内存开销和处理时间。改用AsNoTrackingWithIdentityResolution，EF Core会在无跟踪模式下解析实体标识，避免重复实例，提升对象组装效率。
• 拆分查询手动组装：若拆分查询无效，可将复杂查询拆分为多个小型查询，手动组装实体层级。例如先查询Bike和FrameProfile，再单独查询BikeConfigurations及其关联属性，最后通过代码关联到Bike对象上——虽增加代码量，但可避免EF Core生成过于复杂的SQL，减少查询执行的不确定性。

四、数据库层面的优化 #

• 更新统计信息：测试环境数据量少，但统计信息可能过期，导致数据库选择低效的执行计划。手动执行UPDATE STATISTICS更新所有相关表的统计信息，帮助数据库生成更优的执行计划。
• 检查索引碎片：即使数据量少，若表有频繁的增删改，可能产生索引碎片，影响查询性能。执行DBCC SHOWCONTIG查看索引碎片情况，必要时重建索引。

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