EF6执行存储过程修改表未调用SaveChanges的行为是怎样的

核心结论 #

你遇到的现象和SaveChanges没有任何关系，本质是FromSqlRaw的延迟执行特性导致的命令发送时机不确定，不存在所谓“DbContext复用触发隐式提交”的逻辑。

关键行为规则 #

• EF的SaveChanges()只负责处理变更追踪器跟踪的内存变更：也就是你通过DbSet.Add/Update/Remove、直接修改跟踪实体属性产生的变更，这些变更存在EF内存中，只有调用SaveChanges()时才会被编译成SQL发送到数据库；如果没调用SaveChanges，DbContext被回收时这些内存变更会直接丢弃，完全不会影响数据库数据。
• 通过FromSqlRaw、FromSqlInterpolated等方法直接编写的SQL/存储过程调用，完全不走变更追踪链路，SaveChanges()管不到这些操作的提交回滚，这类操作的事务行为完全由数据库侧的规则决定：
  • 如果你没有显式开启事务，数据库默认开启自动提交模式，存储过程执行成功的瞬间，对应的数据修改就会被持久化提交，执行失败则自动回滚该存储过程的操作，和EF的生命周期、有没有调用SaveChanges毫无关系。
  • 如果你显式通过ctx.Database.BeginTransaction()开启了事务，那么所有在事务内执行的存储过程操作，都需要手动调用transaction.Commit()才会提交，否则连接关闭时数据库会自动回滚所有未提交的操作。

你观测到“延迟提交”的根本原因 #

你贴的代码里用了FromSqlRaw挂载在DbSet下执行存储过程，这是错误的用法：
FromSqlRaw返回的是IQueryable类型，天生带有延迟执行特性——你写的两行EXEC myUsp1、EXEC myUsp2在方法执行时只是在内存中定义了查询规则，根本没有打开数据库连接、也没有把命令发送到数据库，自然不会立刻产生数据修改。

这类IQueryable只有在被实际枚举时才会触发真实的数据库执行，触发时机完全不确定：

• 如果IQueryable被作为返回值传出方法、被其他变量持有，后续代码调用ToList()、First()、foreach遍历等操作时，才会真的执行存储过程，执行完成后数据立刻被数据库自动提交，这就是你看到“一段时间后才出现数据修改”的原因。
• 如果IQueryable没有被任何代码持有，等GC回收该对象后，对应的存储过程永远不会执行，数据库也不会产生任何对应修改。
• 所谓“DbContext复用触发提交”只是巧合：本质是复用DbContext执行其他操作时，刚好意外枚举到了之前定义的未执行IQueryable，才触发了存储过程执行，EF本身没有任何“复用DbContext时自动提交未保存变更”的逻辑。

正确写法 #

执行带增删改操作的存储过程，不要用面向查询设计的FromSqlRaw，应该用Database访问层下的ExecuteSqlRaw/ExecuteSqlInterpolated方法，这类方法是立即执行的，调用时就会把命令发送到数据库，不会有延迟执行的坑：

public void CallUpdate()
{
  var ctx = Factory.CreateDbContext();
  ctx.Database.SetCommandTimeout(TimeSpan.FromMinutes(10));
  // 立即执行存储过程，无延迟，不需要调用SaveChanges
  ctx.Database.ExecuteSqlRaw("EXEC myUsp1");
  ctx.Database.ExecuteSqlRaw("EXEC myUsp2");
}

如果需要保证多个存储过程的原子性，记得显式开启事务：

public void CallUpdateWithTransaction()
{
  var ctx = Factory.CreateDbContext();
  ctx.Database.SetCommandTimeout(TimeSpan.FromMinutes(10));
  using var tx = ctx.Database.BeginTransaction();
  try
  {
    ctx.Database.ExecuteSqlRaw("EXEC myUsp1");
    ctx.Database.ExecuteSqlRaw("EXEC myUsp2");
    tx.Commit();
  }
  catch
  {
    tx.Rollback();
    throw;
  }
}

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