使用CancellationToken取消含While循环的SQL查询时无限挂起

我碰到过类似的情况，你遇到的这个问题其实是SQL Server的取消机制和.NET SqlClient的实现细节共同作用的结果，咱们一步步拆解：

为什么Cancel()会无限挂起？ #

当你调用CancellationTokenSource.Cancel()时，.NET SqlClient会向SQL Server发送一个查询取消请求，但SQL Server只有在执行到特定的「取消点」时才会响应这个请求。而你写的这个紧凑WHILE循环：

WHILE 1 = 1
BEGIN
    DECLARE @x INT = 1
END

是一个完全没有取消点的代码——它一直在执行极其简单的内存赋值操作，全程不会触发SQL Server的取消检查逻辑。这就导致SQL Server根本没机会处理.NET发来的取消请求，.NET端的线程就一直等着服务器响应，最终无限挂起。

为什么SSMS能立即取消？ #

SSMS用的是更直接的方式：它会直接发送KILL命令终止对应的查询会话（或者说查询进程），这种方式不依赖查询内部的取消点，属于强制终止，所以不管你的循环有没有取消点都能立刻生效。

可行的解决方案 #

1. 给SQL查询添加取消点 #

最简单的办法是在循环里加入一个能触发取消检查的操作，比如WAITFOR DELAY（哪怕是极短的延迟），或者RAISERROR WITH NOWAIT（SQL Server 2012+也可以用THROW但要注意场景）。修改后的SQL如下：

WHILE 1 = 1
BEGIN
    DECLARE @x INT = 1
    WAITFOR DELAY '00:00:00.001' -- 加入这个，让SQL Server每次循环都检查取消请求
END

这样每次循环时，SQL Server都会检查是否有未处理的取消请求，就能正常响应.NET的取消命令了。

2. 强制终止连接（极端情况） #

如果必须保留无取消点的循环，可以考虑在取消时直接关闭数据库连接，这会强制终止查询，但代价是整个连接会被关闭，需要根据你的业务场景权衡：

// 在取消时调用，注意线程安全
await connection.CloseAsync().ConfigureAwait(false);

补充说明 #

你提到升级到SQL Server 2017问题依然存在，这是因为SQL Server的取消点机制在各个版本中都是一致的——只有当查询执行到I/O操作、等待操作、某些系统函数调用等场景时，才会触发取消检查。纯内存计算的紧凑循环不会触发这些检查。

另外你捕获到的堆栈跟踪显示另一线程卡住，本质就是那个线程在等待SQL Server响应取消请求，但服务器因为没有取消点根本没处理这个请求，所以一直处于挂起状态。

内容的提问来源于stack exchange，提问作者ChaseMedallion