CommandTimeout 控制数据库命令执行阶段超时（如 SQL EXECUTE），不影响后续读取、反序列化等；可全局配置于OnConfiguring，或运行时用SetCommandTimeout动态调整，但不支持单个查询单独设置。
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 是基础但关键的一环，设得太短容易误杀正常慢查，设得太长又掩盖性能问题。结合索引优化、投影裁剪、禁用追踪一起用，效果更稳。
