EF Core 5：更新时态表后调用存储过程偶发死锁问题咨询

• EF Core隐式事务的锁释放延迟
  尽管await SaveChangesAsync()会等待事务提交，但SQL Server在事务结束后不会立刻释放所有锁——尤其是时态表更新时，会同时操作当前表和系统维护的历史表，这两个表的锁释放存在微小时间差。后续存储过程的时态查询（比如带FOR SYSTEM_TIME的语句）如果刚好在锁未完全释放时访问同范围数据，就可能触发锁竞争。

• DbContext连接复用导致的会话状态残留
  同一DbContext实例会复用数据库连接，SaveChangesAsync完成后，连接可能仍保留着事务后的状态，没有完全重置。当调用ExecuteSqlInterpolatedAsync时，复用的连接可能带着未彻底释放的锁痕迹，进而引发逻辑上的锁冲突。可以尝试在SaveChangesAsync后手动调用DbContext.Database.CloseConnection()再重新打开，或者改用全新的DbContext实例执行存储过程来验证。

• 时态表的特殊锁机制与并发竞争
  时态表的历史表由SQL Server自动维护，更新当前表时会对历史表加锁；而存储过程的时态查询通常需要读取历史表数据。如果生产环境存在其他会话同时操作相关数据，就容易出现跨表的死锁——测试环境并发量低，所以无法复现。可以检查存储过程的查询语句，尝试通过添加WITH (NOLOCK)（需权衡数据一致性）、缩小查询范围或优化索引来降低锁粒度。

• 异步线程切换带来的会话状态差异
  虽然用了await确保逻辑顺序，但异步操作可能切换线程，而SQL Server的锁是绑定到数据库会话的。如果SaveChangesAsync和ExecuteSqlInterpolatedAsync在同一连接但不同线程执行，可能出现会话状态的微妙差异，导致锁释放时机和预期不符。改用独立的DbContext执行存储过程，能确保是全新的数据库会话，避免这类干扰。

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