.NET 4.8与.NET 7中EF/LINQ查询性能差异排查求助

问题背景 #

我维护两个应用程序：

• ApplicationA：基于.NET 4.8，使用Entity Framework
• ApplicationB：基于.NET 7，是ApplicationA的现代化版本，服务端核心代码完全一致，同样依赖Entity Framework

两者执行相同数据库查询时，性能差异显著。相关查询代码如下：

using (DbContextEx db = new DbContextEx)  
{  
    /*Query1)*/
    MyObject myObject = db.MyObjects
                          .Where(mo => mo.Type == "MyType" && mo.Id == "MyId")
                          .FirstOrDefault();

    /*Query2) 此处有动态创建查询的代码，两个项目中逻辑一致，后续执行： */
    object obj = query.FirstOrDefault();
}

性能测试结果 #

• ApplicationA：
  • Query #1：4.7秒
  • Query #2：4.6秒
• ApplicationB：
  • Query #1：11.7秒
  • Query #2：11.6秒

已排查代码层面（方法、对象、属性定义）无差异，唯一变量为LINQ及.NET运行时版本。

排查过程更新 #

2024年8月30日更新 #

手动在SSMS中执行生成的SQL耗时4.7秒；改用原生SqlDataReader测试时，ApplicationA耗时4.6秒，ApplicationB耗时10.7秒，排除Entity Framework的影响。测试代码：

using (SqlConnection myConnection = new SqlConnection("MySQLConnection")) 
{
    myConnection.Open();  
    String sql = "MySelectStatement";

    using (SqlCommand command = new SqlCommand(sql, myConnection))
    {
        using (SqlDataReader reader = command.ExecuteReader())
        {
            var dataTable = new DataTable();
            dataTable.Load(reader);
        }
    }
}

2024年8月30日更新2 #

定位到问题触发条件：仅当查询涉及XML数据类型列时，两个应用才出现大幅性能差异，推测是不同.NET版本中ADO.NET处理XML数据的逻辑发生了变化，现寻求该差异的原因排查方向。

排查建议 #

1. 对比XML列读取逻辑差异
   • .NET 4.8中SqlDataReader读取XML列默认依赖SqlXml类型，.NET 7可能调整了解析逻辑（如默认启用严格XML验证、切换底层XML解析器）。可在.NET 7中尝试手动调用reader.GetSqlXml(index)读取XML列，对比性能变化；
   • 检查.NET 7是否默认启用了额外的XML处理步骤（如命名空间解析、DTD验证），尝试通过配置禁用这些功能后测试性能。
2. 核对SQL客户端驱动版本与配置
   • .NET 7默认使用Microsoft.Data.SqlClient，而.NET 4.8默认依赖System.Data.SqlClient（也可兼容前者）。确认两个应用使用的驱动版本及XML相关配置参数（如EnableXmlReaderStreaming）是否一致；
   • 尝试在.NET 7项目中切换为System.Data.SqlClient（若业务兼容），验证性能是否恢复。
3. 分析XML序列化/反序列化环节
   • 如果查询后需要将XML列反序列化为对象，对比两个.NET版本中XmlSerializer的性能差异。.NET 7对XmlSerializer有优化，但默认配置（如序列化选项）的变化可能导致性能波动；
   • 若XML数据体积较大，检查.NET 7是否采用了不同的内存分配策略，尝试手动使用内存流读取XML数据，对比性能。
4. 捕获性能分析数据
   • 使用.NET性能分析工具（如dotTrace）分别对两个应用的查询过程进行采样，重点查看XML数据读取、解析阶段的CPU及内存占用，定位耗时差异的具体环节；
   • 确认SQL Server执行计划一致，排除数据库层面的参数嗅探、执行计划缓存等干扰因素。

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