17370845950

EF Core超时需分三类处理：命令超时（CommandTimeout）控制SQL执行时间，可全局、连接字符串或运行时设置；连接超时（Connect Timeout）仅限连接阶段，须在连接字符串中配置；大结果集卡在结果消费阶段，应结合CancellationToken、分页、投影和AsNoTracking优化。

EF Core超时错误通常不是单一原因导致的，而是命令执行、连接建立、结果读取三个环节中某一个卡住了。解决的关键是分清类型、精准设值，而不是盲目拉长超时时间。

命令超时（CommandTimeout）怎么设才有效

这是最常配置也最容易误解的超时——它只控制 SQL 语句在数据库里“执行完”的时间，不包括网络传输、结果反序列化或内存处理。

• 全局设置（推荐用于多数场景）：在 OnConfiguring 中统一指定

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
  optionsBuilder.UseSqlServer("Server=.;Database=MyDb;", options => options.CommandTimeout(120));
}

• 连接字符串内设（简单直接，适合开发/测试环境）：Command Timeout=120;
• 运行时动态调整（如某个报表查询特别慢）：context.Database.SetCommandTimeout(300);
• 注意：设为 0 表示无限等待（不建议生产环境使用）

连接超时（Connect Timeout）别和命令超时搞混

它只管“连上数据库”这一步，比如网络抖动、SQL Server 服务没启、防火墙拦截等场景。一旦连接成功，这个超时就失效了。

• 必须通过连接字符串设置，EF Core 不提供 API 动态修改
• 典型写法：Server=.;Database=MyDb;Connect Timeout=30;
• 一般保持默认 15 秒即可；若部署在弱网环境（如云函数冷启动），可适当加到 30 秒

大结果集超时？命令超时救不了你

当查询返回几十万行数据时，CommandTimeout 到期前 SQL 已执行完，但 ToListAsync() 还在拼命读、映射、分配内存——这时真正卡住的是“消费结果”阶段。

• 正确做法是用异步取消令牌限制整体耗时

• 配合分页（Skip/Take）、投影（Select 只取需要字段）、流式读取（AsNoTracking()）效果更明显
• 如果必须导出全量，考虑改用 SqlDataReader 手动流式处理，绕过 EF 的对象映射开销

迁移（Migrations）超时怎么办

执行 dotnet ef database update 时卡住，常见于加索引、重建大表、数据迁移脚本复杂等情况。此时不是代码问题，而是迁移工具本身超时了。

• EF Core 7+ 支持在 Migrations\Configuration.cs 构造函数中设全局迁移超时

• 或者临时用命令行参数：dotnet ef database update --command-timeout 1800
• 根本解法仍是优化迁移脚本：拆分大操作、避免锁表、提前建好索引再灌数据

基本上就这些。超时不是越设越大越好，而是要先定位卡在哪一环，再选对方法。多数线上问题，其实是查询没走索引、没分页、或一次性加载太多实体导致的。