BEGIN TRANSACTION 仅标记显式事务起点，事务行为由 COMMIT/ROLLBACK 决定；默认不自动回滚错误语句，需 SET XACT_ABORT ON 保障一致性。
直接回答：在 SQL Server 中，BEGIN TRANSACTION 本身不能“实现事务控制”——它只是开启一个显式事务的起点；真正决定事务行为的是后续的 COMMIT 或 ROLLBACK，以及是否启用隐式事务模式、是否在错误时自动回滚（这需要 SET XACT_ABORT ON 配合）。
为什么 EXEC 后事务没回滚？——XACT_ABORT 缺失是常见原因
很多开发者写完带 BEGIN TRANSACTION 的存储过程，测试时发现某条语句报错（比如主键冲突、类型转换失败），但前面已执行的 INSERT 却没被撤销。根本原因是：SQL Server 默认不因运行时错误自动回滚整个事务。
必须显式启用强一致性事务终止机制：
-
SET XACT_ABORT ON应放在BEGIN TRANSACTION之前，且作用域覆盖整个批处理 - 它让任何运行时错误（包括约束违反、死锁、超时）立即触发事务中止，后续语句不再执行，且事务处于不可提交状态
- 没有它，单条语句失败后事务仍“活动”，后续语句若成功，
COMMIT会把部分修改持久化
示例片段：
CREATE PROC usp_transfer_money
@from_id INT, @to_id INT, @amount DECIMAL(10,2)
AS
BEGIN
SET XACT_ABORT ON; -- 关键！不可省略
BEGIN TRANSACTION;
<pre class='brush:php;toolbar:false;'>UPDATE accounts SET balance -= @amount WHERE id = @from_id;
UPDATE accounts SET balance += @amount WHERE id = @to_id;
COMMIT;END;
嵌套事务不起作用——SQL Server 实际只认最外层
SQL Server 不支持真正意义上的嵌套事务。多次 BEGIN TRANSACTION 只会增加 @@TRANCOUNT 计数器，但 COMMIT 每次只减 1，只有当 @@TRANCOUNT 归零时才真正提交；而 ROLLBACK 会直接清空所有层级并置 @@TRANCOUNT 为 0。
这意味着：
- 在存储过程中调用另一个含
BEGIN TRANSACTION的存储过程，不会创建隔离的子事务 - 内层
ROLLBACK会连同外层一起回滚，无法“局部回滚” - 依赖
SAVE TRANSACTION+ROLLBACK TO实现部分回滚是可行的，但需手动管理保存点名，且不能跨存储过程边界
安全做法是：只在顶层存储过程中开启事务，被调用的子过程不碰 BEGIN/COMMIT/ROLLBACK，仅做数据操作。
延迟持久事务（DELAYED_DURABILITY）对存储过程的影响
如果你在高吞吐场景下启用延迟持久事务（通过数据库级设置或在 COMMIT 时指定 WITH (DELAYED_DURABILITY = ON)），要注意它只改变日志刷盘时机，不影响事务逻辑控制流。
但有两点易被忽略：
- 即使用了
DELAYED_DURABILITY，ROLLBACK依然立即生效，未刷盘的日志记录会被丢弃 -
SET XACT_ABORT ON与延迟持久性不冲突，但错误发生后事务中止，未刷盘的修改自然丢失——这点和完全持久事务一致 - 如果业务能容忍极小概率（如断电瞬间）的数据丢失，延迟持久可提升
COMMIT延迟；否则应坚持默认的完全持久模式
如何安全返回错误并确保回滚？——别只靠 TRY/CATCH
TRY/CATCH 块能捕获大部分错误，但它无法捕获某些严重错误（如编译错误、对象不存在、权限不足），这些错误会在进入 TRY 前就中断执行，导致事务悬空。
可靠方案是组合使用：
-
SET XACT_ABORT ON处理运行时错误（强制中止） -
TRY/CATCH捕获可控错误，做日志记录或自定义返回值 -
IF @@TRANCOUNT > 0 ROLLBACK放在CATCH块末尾，双重保险
关键不是“有没有 TRY/CATCH”，而是 XACT_ABORT 是否开启——这是防止事务泄露的底线。
