SET XACT_ABORT ON必须置于BEGIN TRANSACTION之前；否则事务出错时仅部分语句回滚，导致孤立数据。它需在会话级显式设置，不继承触发器或子过程状态，且审计日志应脱离主事务独立提交。
SET XACT_ABORT ON 必须放在 BEGIN TRANSACTION 之前
很多存储过程里写了 BEGIN TRANSACTION，然后才设 SET XACT_ABORT ON，这等于没设。SQL Server 的 SET 语句只对后续执行的语句生效，已经跑过的语句不受影响。一旦第一条 INSERT 成功、第二条因主键冲突失败，而 XACT_ABORT 还没启用，那第一条就留在数据库里了——这就是典型的“孤立事务”：业务逻辑中断了，但部分数据已提交。
正确顺序只有这一种：
SET XACT_ABORT ON; BEGIN TRANSACTION; INSERT INTO Users (ID, Name) VALUES (1, 'Alice'); INSERT INTO Profiles (UserID, Bio) VALUES (1, ''); -- 若此处失败，上面的 Users 插入也会被回滚 COMMIT TRANSACTION;
-
SET XACT_ABORT ON要紧贴存储过程开头，或至少在BEGIN TRANSACTION前一行 - 不要把它塞进 TRY 块里——它必须在事务启动前就生效
- 即使你用
TRY...CATCH，XACT_ABORT ON仍是前提；否则某些约束错误（如Msg 2627）根本不会进 CATCH，直接终止批处理但不回滚
别指望触发器默认值能“传染”到你的存储过程
触发器里 XACT_ABORT 默认是 ON，但这和你的存储过程完全无关。每个会话、每个批处理都独立维护自己的 SET 状态。你在 SSMS 里手动执行脚本、用 .NET 的 SqlCommand 调用、或者通过链接服务器调用，都会继承各自连接的默认设置（通常是 OFF）。
常见踩坑场景：
- 用 SQL Server Management Studio 执行时没显式设，靠“以前试过没问题”侥幸
- 存储过程里调用了另一个存储过程，以为子过程里设了就行——错，父过程仍按自己会话的设置运行
- 客户端启用了连接池，旧连接残留了上一次的
XACT_ABORT OFF状态，新请求复用后直接中招
并发插入重复时，XACT_ABORT 不管用
XACT_ABORT ON 解决的是“出错后是否全回滚”，不是“如何避免出错”。两个事务同时查某用户不存在，然后都去 INSERT，必然触发主键冲突——这时 XACT_ABORT ON 能保证各自事务完整回滚，但它无法阻止冲突发生。
要真正防止这类竞态，得加锁提示或重试逻辑：
- 用
SELECT ... WITH (UPDLOCK, HOLDLOCK)在检查阶段就锁定范围，确保“查+插”原子化 - 捕获
Msg 2627后，在 CATCH 块里做重试或降级处理，而不是依赖自动回滚 - 避免在高并发写场景下纯靠应用层判断，把存在性校验下沉到带锁的存储过程中
审计日志不能和主事务绑在一起
有人想“既然主事务要回滚，日志也该跟着回滚”，结果导致故障发生时，连哪条语句失败、谁执行的、参数是什么都查不到。审计日志必须脱离主事务控制，否则就是自我掩埋证据。
安全写法是显式断开事务传播：
-- 主事务部分（带 XACT_ABORT ON）
SET XACT_ABORT ON;
BEGIN TRANSACTION;
UPDATE Orders SET Status = 'Shipped' WHERE ID = @OrderID;
-- ... 其他业务操作
<p>-- 审计日志：强制不参与主事务
SET XACT_ABORT OFF;
BEGIN TRY
INSERT INTO AuditLog (ProcName, ExecutedBy, Params)
VALUES ('sp_ShipOrder', SUSER_NAME(), @Params);
END TRY
BEGIN CATCH
-- 日志失败不中断主流程
END CATCH;</p><p>COMMIT TRANSACTION;关键点在于：SET XACT_ABORT OFF 配合 TRY...CATCH，让日志写入变成“尽力而为”，而不是主业务的负担。这点容易被忽略，但线上事故复盘时，90% 的时间都花在找“到底谁、什么时候、干了什么”上。
