当然可以。Dapper 查询设置超时时间，核心就是 CommandTimeout 参数。它并不是 Dapper 自己搞的一套“超时逻辑”，而是直接透传给底层 ADO.NET 的 SqlCommand.CommandTimeout（单位：秒），由数据库驱动层真正执行中断或抛出异常。

直接在方法调用中指定超时

这是最常用、也最清晰的做法，优先级最高，会覆盖其他任何配置：

• 同步查询：connection.Query(sql, param, commandTimeout: 20)
• 异步查询：await connection.QueryAsync(sql, param, commandTimeout: 30)
• 执行非查询语句：connection.Execute(sql, param, commandTimeout: 15)

全局默认超时设置

适合多数查询节奏一致的项目，省得每处都重复写参数。

设置一次即可全局生效：SqlMapper.Settings.CommandTimeout = 30;

该值为 int 类型，默认是 null，表示使用数据库连接自身的默认值（通常是 30 秒）。

需要注意的是，它会被方法级的 commandTimeout 覆盖，不会影响已显式传参的调用。

配合 CancellationToken 实现更可靠的超时控制

话虽如此，commandTimeout 只负责数据库命令级超时，连接建立、DNS 解析、网络抖动等环节它覆盖不到。

想要做到“最多等 20 秒”的端到端控制，推荐组合 CancellationToken：

• 创建带延迟的取消令牌：var cts = new CancellationTokenSource(TimeSpan.FromSeconds(20));
• 传入异步方法：await connection.QueryAsync(sql, param, commandTimeout: 15, cancellationToken: cts.Token);

这样一来，即使数据库命令本身没超时，整个操作也会在 20 秒后主动取消，避免线程或连接被卡住。

超时优先级与避坑提醒

Dapper 按以下顺序决定最终的超时值（从高到低）：

• 方法参数中的 commandTimeout
• CommandDefinition 构造时传入的 CommandTimeout
• 全局 SqlMapper.Settings.CommandTimeout
• 连接字符串里的 Connect Timeout=XX（只影响连接建立，不等于命令超时）
• ADO.NET 驱动默认值（如 SqlClient 默认 30 秒）

有一点必须警惕：不要设为 0（无限等待），很容易拖垮连接池。

高频简单查询建议 5–10 秒，报表类可以放宽到 60–120 秒。

真正需要注意的是：超时只是失败时的兜底方案，治本还得靠索引优化、SQL 重写和连接池监控。

《夸克》非常好用的免费AI浏览器

下载APP查看