EF Core 的
CommandTimeout控制的是数据库命令执行阶段的超时（比如 SQL 的
EXECUTE或
EXECUTE READER），不是整个查询加载或序列化过程。它只管“SQL 执行多久没出结果就报错”，不管后续读取大量数据、反序列化、内存分配等耗时环节。
全局设置 CommandTimeout（推荐用于多数场景）
在
OnConfiguring中配置，影响该 DbContext 实例的所有命令：
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(
"Server=.;Database=MyDb;Trusted_Connection=True;",
options => options.CommandTimeout(60) // 单位：秒
);
}
这个设置对
SaveChanges、
ToList()、
CountAsync()等所有触发 SQL 执行的操作都生效。
运行时动态设置（适合临时调整）
用
Database.SetCommandTimeout()可以在某个上下文实例上临时覆盖全局值： 对当前
DbContext实例后续所有命令生效，直到再次调用该方法或实例释放 不跨线程、不跨实例，适合按需控制高风险查询 示例：
context.Database.SetCommandTimeout(TimeSpan.FromSeconds(15));
注意：它不能为单个 LINQ 查询单独设超时——改了就是改整个上下文实例的默认行为。
连接字符串里也能设（仅限连接建立）
连接超时（
Connect Timeout）和命令超时（
Command Timeout）是两回事：
Connect Timeout=30：只管“连上数据库服务器”要花多久，跟 SQL 执行无关
Command Timeout=60：才真正控制 SQL 执行时间，必须通过 provider options 或
SetCommandTimeout设置 MySQL/PostgreSQL 等其他提供程序写法略有不同，但语义一致
超时没生效？常见原因和应对
如果设置了
CommandTimeout却发现查询仍长时间卡住，很可能是以下情况： SQL 已执行完，但返回了百万行数据，EF Core 正在逐行读取、映射、跟踪——这部分不受
CommandTimeout约束 用了
AsNoTracking()但数据量极大，网络传输或 GC 压力导致延迟 未加索引导致 SQL 执行本身慢，但超时值设得过大，或者被其他锁阻塞 异步操作没配合
CancellationToken，单纯靠
CommandTimeout无法中断整个 await 链
真要限制端到端耗时，建议组合使用：
SetCommandTimeout()+ 异步方法传入带超时的
CancellationToken，例如：
await query.ToListAsync(new CancellationTokenSource(TimeSpan.FromSeconds(30)).Token);
基本上就这些。CommandTimeout 是基础但关键的一环，设得太短容易误杀正常慢查，设得太长又掩盖性能问题。结合索引优化、投影裁剪、禁用追踪一起用，效果更稳。
