EF Core 3.1下BeginTransactionAsync偶发数秒长耗时问题咨询

数据库层面锁相关结论 #

BeginTransactionAsync 本身不会在Azure SQL（底层为SQL Server）层面触发会阻塞其他业务会话的长持有锁，但执行过程中可能遇到两类隐性资源排队，表现出的耗时特征和你观测到的情况完全吻合：

• 事务日志资源锁：每次开启新事务需要向事务日志文件申请写入预留空间，若当前虚拟日志文件（VLF）正在被归档、刷新到磁盘，或者弹性池的日志吞吐上限被瞬时打满，会触发LOGMGR_RESERVE_APPEND、WRITELOG类等待，这类等待不会反映在弹性池整体CPU/eDTU使用率统计中，属于瞬时资源争抢
• 系统表元数据锁：开启事务时需要更新数据库级别的事务统计元数据，高并发下如果有大量事务同时创建，会出现极短的元数据锁排队，极端情况下也会出现秒级耗时

适配你场景的排查优化方案 #

• 首先开启Azure SQL的查询存储（Query Store），筛选高耗时时段的等待事件，若存在大量上述日志类等待，可确认是日志资源瓶颈，可通过调整弹性池IO配额、优化事务提交频率缓解
• 检查EF Core连接池配置：默认连接池最大连接数为100，多租户高并发场景下很容易触顶，导致BeginTransactionAsync阻塞等待空闲连接，可在连接字符串中添加Max Pool Size=200调整上限（根据实际并发量调整，最高不建议超过1000）
• 排查长事务问题：确认所有事务都通过using声明自动释放，没有持有事务超过必要时间，长事务会持续占用连接资源，加剧连接池排队问题
• 调整事务创建逻辑：如果是高频短事务场景，可考虑使用EF Core的隐式事务机制，避免手动频繁创建显式事务，降低事务创建的开销

内容的提问来源于stack exchange，提问作者Søren Lorentzen