.NET Core 3.1升级至6后Azure应用EF Core 6查询性能骤降求助

核心现象分析 #

你的情况核心矛盾很明确：本地环境EF执行快、直接跑EF生成的SQL也快，但生产Azure Web App中EF执行极慢，说明问题不在SQL语句本身，而是EF Core在生产环境的执行流程、配置或环境差异导致的。

具体排查步骤 #

1. 排查隐性客户端评估

EF Core 3.1开始默认禁止客户端评估，但6.0的规则细节有微调，可能存在未触发警告的隐性客户端评估（比如关联数据的处理）。可以在DbContext的OnConfiguring中添加配置，强制客户端评估抛出异常：

optionsBuilder.ConfigureWarnings(warnings => 
    warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));

部署后观察是否有相关异常抛出——如果有，说明EF在客户端拉取了大量数据进行过滤/关联，这是性能瓶颈的核心原因。

2. 检查数据库连接与配置差异

• 对比本地和生产的连接字符串：确认是否启用了连接池（默认启用），检查Max Pool Size设置是否合理，避免因连接等待导致延迟；
• 检查是否开启了MultipleActiveResultSets=True：MARS在部分关联查询场景下会增加额外开销，可尝试临时关闭测试性能变化；
• 验证生产环境的SQL Server连接是否存在网络延迟：在Azure Web App中通过Kudu工具执行网络测试（比如tcping <数据库地址> 1433），确认网络RTT是否远高于本地。

3. 跟踪EF Core的完整执行日志

在生产/ staging环境开启EF Core的详细查询日志，重点跟踪Microsoft.EntityFrameworkCore.Database.Command类别，查看：

• SQL语句的执行耗时（对比直接跑SQL的时间）；
• 结果从数据库返回后，客户端映射的耗时；
• 参数传递是否正确（比如Contains的参数是否和预期一致）。
  日志配置示例：

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Debug, new[] { DbLoggerCategory.Database.Command.Name });

通过日志对比本地和生产的执行流程，定位是SQL执行阶段慢，还是客户端映射阶段慢。

4. 排查参数嗅探或执行计划问题

虽然直接跑SQL快，但EF传递参数的方式可能导致SQL Server选择不同的执行计划：

• EF Core 6对Contains的处理逻辑有调整，当ids数量较多时，可能从3.1的IN子句改为表值参数（TVP）；如果是TVP，需确认对应的表值类型是否匹配，且是否为其创建了索引；
• 可尝试在查询中添加AsNoTracking()，关闭变更跟踪，测试性能是否提升（变更跟踪在大数据量映射时会有额外开销）。

5. 检查Azure Web App运行时配置

• 确认Web App的运行时确实是.NET 6，未意外 fallback到旧版本；
• 检查是否启用了ReadyToRun（R2R）编译：虽然R2R通常提升性能，但个别场景下可能存在优化异常，可临时关闭测试；
• 确认Web App的实例规格是否足够：即便CPU/内存未高负载，资源瓶颈可能出现在磁盘IO或网络带宽上（可在Azure Portal查看Web App的监控指标）。

针对示例查询的优化建议 #

对于你提供的Linq查询，可尝试以下改写，避免先ToList再Contains的拆分逻辑：

var groups = await dbContext.Groups
    .Include(g => g.UserGroups)
    .Where(g => notifications.Select(n => n.GroupId).Contains(g.GroupId))
    .ToListAsync();

这种写法让EF直接生成关联查询，而非IN子句，在notifications数量较大时性能更稳定。

总结 #

不要急于逐个改写查询，先通过上述步骤定位根因——大部分这类升级后的性能问题都是配置差异、环境限制或隐性执行行为变更导致的，而非EF Core查询生成逻辑需要全面重构。

内容的提问来源于stack exchange，提问作者Bruce De Jager