EF Core 默认不自动重试数据库连接,需显式调用 EnableRetryOnFailure 启用弹性策略,仅针对网络抖动、瞬时超时等临时错误(如 SQL Server 错误 40613/1205、MySQL 错误 1040/2013)有限重试,不处理主键冲突等永久性错误;重试适用于查询、SaveChangesAsync 和迁移,但不覆盖手动事务;默认指数退避,需关注内存开销、事务幂等性和日志监控;可扩展使用 Polly 实现更精细控制。
EF Core 本身不自动重试失败的数据库连接,但可以通过 EnableRetryOnFailure 显式启用弹性连接策略,专门应对网络抖动、瞬时超时、连接池耗尽等短暂故障。它不是万能兜底,而是针对可识别的“临时性错误”(如 SQL Server 错误 40613、40197、1205 等)做有限重试。
在注册 DbContext 时配置即可,适用于 SQL Server 和 MySQL(Pomelo 提供支持):
services.AddDbContext
options.UseSqlServer(connectionString, sqlOptions =>
sqlOptions.EnableRetryOnFailure(
maxRetryCount: 5,
maxRetryDelay: TimeSpan.FromSeconds(30),
errorNumbersToAdd: null)));
Pomelo.EntityFrameworkCore.MySql):services.AddDbContext
options.UseMySql(connectionString, new MySqlServerVersion(new Version(8, 0, 33)),
mySqlOptions => mySqlOptions.EnableRetryOnFailure(5)));
SaveChangesAsync()、迁移执行(如 Database.Migrate())BeginTransactionAsync() 不会被自动包裹进重试范围,整个事务需由你自行保障原子性EF Core 内置判断逻辑,对以下典型场景自动视为可重试:
errorNumbersToAdd 补充自定义错误码(如 Azure SQL 的特定限流码)启用后不是“零成本”,需关注实际运行表现:
SaveChangesAsync() 成为独立可重试单元;跨多个 SaveChanges 的业务逻辑需自行幂等设计LogLevel.Information 级别),观察重试是否频繁触发——高频重试往往说明存在根本问题(如连接池设置过小、慢查询拖垮服务)ConnectRetryCount 和 ConnectRetryInterval 是 ADO.NET 层参数,与 EF Core 的 EnableRetryOnFailure 并存但作用域不同,一般推荐只用后者,更可控当内置策略不够灵活(比如只想重试某几个关键查询、要记录每次重试上下文、或整合熔断/降级),可用 Polly 库手动实现:
Polly + Polly.Extensions.Http(虽名含 Http,也适用于 DB 场景)IsTransient 方法)基本上就这些。合理设好重试次数和延迟,配合日志观察,能明显改善云环境或高并发下的数据库稳定性。但它不是掩盖架构问题的胶带——如果重试频繁发生,优先查连接池、SQL 性能、网络链路或数据库负载。