从.NET Core 1迁移至.NET Core 2.1后应用性能下降一倍的原因排查

结合你提到的迁移场景（从ASP.NET Core 1.x升级到2.1，使用EF Core 2.1 RC1版本），我整理了几个常见的性能瓶颈点，你可以逐一验证排查：

1. 优先解决RC版本的潜在问题 #

你当前使用的Microsoft.EntityFrameworkCore.SqlServer是2.1.0-rc1-final——RC（候选发布版）主要用于功能验证，通常存在未优化的性能逻辑或已知bug。ASP.NET Core 2.1正式版后续发布了多个补丁（比如最新的2.1.16），修复了大量RC阶段的性能缺陷。建议先升级到2.1.x的稳定正式版，再重新测试性能，这是最快速的排查步骤。

2. EF Core查询行为的默认变更 #

EF Core 2.x对比1.x在查询处理上有不少默认逻辑调整，可能带来额外开销：

• 查询跟踪的默认行为：EF Core 2.0引入了QueryTrackingBehavior全局配置，默认是TrackAll。如果你的应用中有大量只读查询（比如列表展示），没有显式关闭跟踪的话，会增加实体跟踪的开销。可以在DbContext的配置中添加：

  optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
  

  或者在单个查询后追加AsNoTracking()，对比性能变化。
• 查询编译缓存命中率：EF Core 2.x改进了查询编译缓存，但如果你的查询包含大量动态参数、复杂表达式或未参数化的查询，可能导致缓存命中率下降，重复编译查询。可以启用EF Core日志，查看是否频繁出现Compiling query的日志条目。

3. ASP.NET Core管道中间件的额外开销 #

ASP.NET Core 2.1默认启用了一些新中间件（比如UseHsts、UseHttpsRedirection），同时对现有中间件的逻辑做了优化但也可能增加处理步骤。如果你的Startup.cs中保留了不必要的中间件，或者某些中间件配置不当（比如身份验证逻辑更复杂），会增加请求处理的耗时。建议对比1.x版本的Startup.cs，逐步移除非核心中间件，测试性能变化。

4. 数据库连接池配置问题 #

ASP.NET Core 2.x对数据库连接池的默认参数做了调整，比如连接池大小、连接回收逻辑。如果你的应用并发请求较多，连接池配置不合理可能导致频繁的连接创建/销毁开销。可以在连接字符串中显式设置Max Pool Size（比如Max Pool Size=100），同时通过EF Core日志查看是否有连接等待的情况。

5. 依赖注入服务注册的合理性 #

ASP.NET Core 2.1的DI容器做了性能优化，但如果服务注册方式错误，会带来额外开销：

• 比如DbContext如果错误注册为Transient（每次请求创建多次实例），会增加初始化和数据库连接的开销；如果注册为Singleton则会引发严重的线程安全问题。正确的注册方式是Scoped（默认AddDbContext就是Scoped），检查你的Startup.cs中的服务注册代码。
• 大量Transient服务的创建也会增加对象实例化的开销，对于频繁使用的服务，优先考虑Scoped或Singleton。

6. 精准定位的性能分析建议 #

如果上述排查都没有解决问题，建议做针对性的性能分析：

• 启用EF Core的详细日志，对比迁移前后生成的SQL语句，看是否存在更复杂的查询、未命中索引的情况。
• 使用Visual Studio的性能探查器，查看CPU、内存的热点方法，定位到具体的耗时代码段。
• 在SQL Server中执行慢查询的执行计划，检查是否有索引缺失、查询计划退化的问题。

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