存储过程在不少老项目和性能敏感型系统中依然扮演着重要角色，而EF Core作为.NET平台最主流的ORM框架，它对存储过程的支持却显得有些含蓄。很多开发者在使用EF Core调用存储过程时，第一个遇到的坑就是：明明存储过程执行成功，代码却抛出“缺少FROM子句”或“无法映射结果集”之类的异常。这篇文章就来完整梳理EF Core调用存储过程的几种方式，覆盖查询、增删改、输出参数等常见场景，并给出可直接运行的代码示例。
一、为什么EF Core调用存储过程容易踩坑
首先要理解EF Core的设计哲学。EF Core推崇的是“代码优先”和LINQ表达式树，它希望开发者尽量通过实体操作来完成数据访问，而不是直接写SQL。因此EF Core并没有像老版本EF6那样提供Database.SqlQuery这类便捷方法，调用存储过程需要借助原生SQL执行接口。
其次，FromSqlRaw这条链路底层会生成一条真实的SQL语句，例如SELECT * FROM (存储过程调用)这样的结构在某些数据库上是不允许的，因为存储过程不能出现在FROM子句中。所以在SQL Server上，EF Core会自动包裹一层处理，但如果存储过程返回的列名与实体属性对不上，就会直接报“数据读取器与指定实体不兼容”的错误。理解了这些底层机制，后面遇到问题就能快速定位。
还有一个常见误区是：有人试图用FromSqlRaw去执行INSERT、UPDATE、DELETE类型的存储过程，结果发现执行成功但数据没变。原因在于FromSqlRaw走的是查询管道，不会真正提交变更。这类操作必须使用ExecuteSqlRaw系列方法。
二、使用FromSqlRaw调用返回结果集的存储过程
这是最常见的场景：存储过程返回一组数据，前端需要展示列表。前提条件是必须有一个实体类型与存储过程返回的列一一对应，列名要匹配属性名（不区分大小写）。假设我们有如下存储过程：
CREATE PROCEDURE dbo.GetOrdersByStatus
@Status INT
AS
BEGIN
SELECT Id, OrderNo, UserId, Amount, Status, CreateTime
FROM Orders
WHERE Status = @Status
ORDER BY CreateTime DESC
END对应的实体类定义如下：
[Table("Orders")]
public class Order
{
public int Id { get; set; }
public string OrderNo { get; set; }
public int UserId { get; set; }
public decimal Amount { get; set; }
public int Status { get; set; }
public DateTime CreateTime { get; set; }
}调用方式非常简洁，用命名参数防止SQL注入：
var status = 1;
var orders = await _context.Orders
.FromSqlRaw("EXEC dbo.GetOrdersByStatus @Status = {0}", status)
.ToListAsync();
// 推荐使用FromSqlInterpolated，参数自动参数化
var orders2 = await _context.Orders
.FromSqlInterpolated($"EXEC dbo.GetOrdersByStatus @Status = {status}")
.ToListAsync();这里强烈建议使用FromSqlInterpolated或者SqlParameter对象传参，不要直接拼接字符串。虽然FromSqlRaw的占位符{0}内部也会参数化，但混用拼接写法容易留下注入隐患。另外注意，FromSqlRaw返回的是IQueryable，你还可以继续追加Where、OrderBy、Skip、Take等LINQ操作，EF Core会把存储过程结果当作子查询再包装，这在SQL Server上通常可行，但在MySQL上可能报语法错误，需要实际测试。
三、执行增删改类型的存储过程用ExecuteSqlRaw
当存储过程执行的是写入操作，比如批量更新状态、删除过期数据，就应该用Database.ExecuteSqlRaw。它返回受影响的行数，并且走的是命令执行管道，行为类似于ADO.NET的ExecuteNonQuery。
// 方式一：占位符写法
var rows = await _context.Database
.ExecuteSqlRawAsync("EXEC dbo.BatchUpdateOrderStatus @OldStatus = {0}, @NewStatus = {1}", 1, 2);
// 方式二：显式SqlParameter，可读性更好
var p1 = new SqlParameter("@OldStatus", SqlDbType.Int) { Value = 1 };
var p2 = new SqlParameter("@NewStatus", SqlDbType.Int) { Value = 2 };
var rows2 = await _context.Database
.ExecuteSqlRawAsync("EXEC dbo.BatchUpdateOrderStatus @OldStatus, @NewStatus", p1, p2);有一点需要特别注意：ExecuteSqlRaw不会触发EF Core的变更跟踪，也不会自动SaveChanges。如果你的存储过程修改了某些已被跟踪实体的数据，内存中的实体状态可能与数据库不一致。稳妥的做法是执行后调用_context.ChangeTracker.Clear()，或者在查询时使用AsNoTracking，避免脏数据被误用。
对于没有返回结果集、也没有输出参数的简单过程，上面两种方式已经够用。但真实业务中经常需要拿到存储过程的RETURN值或OUTPUT参数，这就要借助输出参数的配置技巧。
四、处理OUTPUT参数和RETURN值
输出参数的坑在于：SqlParameter必须在执行前设置为输出方向，并且在读取结果前不能提前Dispose连接。正确写法如下：
var totalParam = new SqlParameter("@Total", SqlDbType.Int)
{
Direction = ParameterDirection.Output
};
var pageParam = new SqlParameter("@Page", SqlDbType.Int) { Value = 1 };
await _context.Database.ExecuteSqlRawAsync(
"EXEC dbo.GetOrderPage @Page, @Total OUTPUT", pageParam, totalParam);
// 执行完毕后读取输出参数
int total = totalParam.Value == DBNull.Value ? 0 : Convert.ToInt32(totalParam.Value);如果存储过程既有结果集又有OUTPUT参数，EF Core的FromSqlRaw就无能为力了，因为它在读完结果集后就会释放DataReader，输出参数可能取不到。这种情况有两种解决方案：一是改用ADO.NET原生方式，通过DbContext.Connection拿到连接手动执行；二是引入Dapper，它对这种混合场景的处理非常成熟，代码如下：
var conn = _context.Database.GetDbConnection();
if (conn.State != ConnectionState.Open)
await conn.OpenAsync();
using var cmd = conn.CreateCommand();
cmd.CommandText = "dbo.GetOrderPage";
cmd.CommandType = CommandType.StoredProcedure;
var pTotal = cmd.CreateParameter();
pTotal.ParameterName = "@Total";
pTotal.Direction = ParameterDirection.Output;
cmd.Parameters.Add(pTotal);
var pPage = cmd.CreateParameter();
pPage.ParameterName = "@Page";
pPage.Value = 1;
cmd.Parameters.Add(pPage);
using var reader = await cmd.ExecuteReaderAsync();
var orders = new List<Order>();
while (await reader.ReadAsync())
{
orders.Add(new Order
{
Id = reader.GetInt32(0),
OrderNo = reader.GetString(1)
});
}
reader.Close(); // 必须关闭reader后输出参数才可读
int total = Convert.ToInt32(pTotal.Value);关键点在最后一行注释：ADO.NET规定输出参数要等DataReader关闭后才能保证读取到值，这一点无论是EF Core还是Dapper都绕不开，是底层驱动行为。
五、返回非实体类型结果的处理方案
很多存储过程返回的是统计、报表类的临时数据，专门为它建一个实体类加到DbContext里显得很重。EF Core 7及以上提供了Database.SqlQuery泛型方法，可以映射到任意类型，无需注册到DbContext：
// EF Core 7+ 可用，实体不需要配置到DbContext
var summary = await _context.Database
.SqlQuery<OrderSummary>($"EXEC dbo.GetOrderSummary @Month = {6}")
.ToListAsync();
public class OrderSummary
{
public int TotalCount { get; set; }
public decimal TotalAmount { get; set; }
public string Month { get; set; }
}如果项目还在用EF Core 5或6，官方没有这个方法，可以安装社区扩展包EFCore.BulkExtensions或者直接用Dapper补位。Dapper的Query方法同样基于DbConnection，与EF Core共享同一个连接，事务也能打通：
var conn = _context.Database.GetDbConnection();
var list = (await conn.QueryAsync<OrderSummary>(
"dbo.GetOrderSummary",
new { Month = 6 },
commandType: CommandType.StoredProcedure)).ToList();六、常见报错与排查思路
第一种是“The required column 'xxx' was not present in the results”，说明存储过程返回的列与实体属性不一致。检查存储过程中动态SQL拼出的列名、别名，确保每个映射属性都有同名列。实在无法改存储过程的话，可以在实体属性上加[NotMapped]或用Fluent API的Ignore排除。
第二种是“Incorrect syntax near”，多半出现在FROM子句包裹存储过程的情况下，常见于MySQL或Oracle。解决办法是确保EF Core版本至少是2.1以上（对存储过程包裹有优化），或者避免在FromSqlRaw后追加LINQ操作。
第三种是输出参数始终为NULL，除了前面提到的reader未关闭问题，还要检查SqlParameter是否忘了设置Direction为Output，以及存储过程内部是否漏写了SET @Total = ...赋值语句。
最后提醒一点事务问题：如果存储过程内部有事务，而外部又用了BeginTransaction，嵌套不当会造成死锁。建议存储过程内部使用IF @@TRANCOUNT > 0判断后再决定是否开启事务，保证与EF Core外部事务兼容。掌握这些细节后，EF Core与存储过程的配合就再也不会成为项目中的疑难杂症了。
EF Core存储过程FromSqlRaw修改时间：2026-09-14 05:48:42