SQL Server：.NET代码取消存储过程执行时，已开启事务会提交还是回滚？

嘿，这个问题问到点子上了，刚好我有实际处理过类似场景，给你讲明白：

当你从.NET代码里主动取消存储过程的执行（不管是调用SqlCommand.Cancel()、触发CommandTimeout超时，还是因为网络中断、应用崩溃导致执行终止），SQL Server会自动回滚这个未完成的事务，绝对不会提交。

背后的逻辑是这样的： #

SQL Server的事务机制设计里，只要事务所在的批处理或存储过程因为外部中断（不是存储过程内部的业务错误）而被迫终止，数据库引擎会立即触发事务回滚操作，避免出现“悬挂事务”（也就是事务既没提交也没回滚、占用资源的情况）。

常见的几种取消场景验证： #

• 主动调用SqlCommand.Cancel()：当你在.NET里调用这个方法，SQL Server会收到明确的取消请求，立刻终止正在运行的存储过程，同时回滚所有未提交的事务操作。
• 命令超时：如果你的SqlCommand设置了CommandTimeout，当执行时间超过这个阈值，.NET会自动向SQL Server发送取消请求，同样触发事务回滚。
• 连接中断/应用崩溃：如果.NET应用突然崩溃，或者网络连接断开，SQL Server会检测到失效的连接，自动清理该连接上所有未完成的事务，执行回滚。

举个实际的例子 #

假设你有这样的存储过程：

CREATE PROCEDURE [dbo].[LongRunningTransactionalProc]
AS
BEGIN
    BEGIN TRANSACTION
    BEGIN TRY
        -- 执行一些数据操作
        INSERT INTO UserLogs (LogContent) VALUES ('Start processing')
        -- 模拟长时间运行的操作，方便测试取消
        WAITFOR DELAY '00:00:20'
        -- 如果正常执行到这里才提交
        COMMIT TRANSACTION
    END TRY
    BEGIN CATCH
        ROLLBACK TRANSACTION
        THROW
    END CATCH
END

如果在WAITFOR DELAY这段时间里，你从.NET调用了Cancel()，那之前插入的UserLogs记录会被完全回滚，数据库里不会留下这条数据。

需要注意的是：这种外部触发的取消，不会触发存储过程里的CATCH块——因为整个批处理已经被数据库引擎终止了，CATCH逻辑根本没机会执行，但这不影响引擎自动回滚事务。

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