Entity Framework性能优化咨询：Database.SqlQuery调用存储过程执行缓慢问题

我之前也碰到过一模一样的情况——EF的Database.SqlQuery在处理大量数据集时，因为框架本身的实体映射、上下文跟踪等额外开销，会比直接在SQL Server里执行慢很多。针对你返回85000条记录的场景，这里有几个可以尝试的优化方案：

1. 关闭EF实体跟踪（如果不需要修改数据） #

虽然Database.SqlQuery默认不会跟踪实体，但如果你的上下文之前加载过同类型实体，或者有隐性的跟踪逻辑，还是会产生额外开销。可以显式关闭跟踪试试：

var result = await _context.Database.SqlQuery<sp_dataexec>("exec sp_dataexec")
    .AsNoTracking()
    .ToListAsync();

不过这个优化的效果可能有限，核心瓶颈还是EF的映射开销。

2. 改用Dapper（轻量级ORM，性能接近原生SQL） #

Dapper是Stack Overflow团队自己在用的ORM，它的实体映射逻辑非常轻量，性能几乎和直接写ADO.NET一样。用法也很简单：
先安装Dapper的NuGet包，然后直接调用：

using (var connection = new SqlConnection(_context.Database.Connection.ConnectionString))
{
    await connection.OpenAsync();
    var result = await connection.QueryAsync<sp_dataexec>("exec sp_dataexec");
    var dataList = result.ToList();
}

这个方案大概率能把耗时降到接近直接执行存储过程的4秒，因为它砍掉了EF很多不必要的框架开销。

3. 手动用SqlCommand读取数据（极致性能方案） #

如果追求最快速度，可以跳过所有ORM，直接用ADO.NET的SqlCommand手动处理数据读取和映射。虽然代码量多一点，但性能是最优的：

var dataList = new List<sp_dataexec>();
using (var connection = new SqlConnection(_context.Database.Connection.ConnectionString))
{
    await connection.OpenAsync();
    using (var command = new SqlCommand("sp_dataexec", connection))
    {
        command.CommandType = CommandType.StoredProcedure;
        using (var reader = await command.ExecuteReaderAsync())
        {
            while (await reader.ReadAsync())
            {
                var item = new sp_dataexec
                {
                    // 手动映射每一列，示例：
                    Id = reader.GetInt32(reader.GetOrdinal("Id")),
                    DataField = reader.GetString(reader.GetOrdinal("DataField")),
                    // 其他属性依次映射...
                };
                dataList.Add(item);
            }
        }
    }
}

这种方式完全规避了ORM的映射开销，速度和你在SSMS里执行几乎一致，适合对性能极度敏感的场景。

4. 简化实体类与EF配置 #

如果你的sp_dataexec实体类有复杂属性（比如嵌套对象、枚举转换、大量导航属性），EF的映射过程会额外耗时。可以尝试：

• 只保留存储过程返回的必要字段，去掉冗余属性
• 把复杂属性的转换逻辑移到映射完成后处理
• 检查并关闭EF上下文的全局过滤器、实体验证等非必要配置

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