SQL Server存储过程事务默认不自动回滚，必须显式设置SET XACT_ABORT ON才能确保约束错误（如主键冲突）触发整个事务回滚；否则仅当前语句失败，事务仍活动（XACT_STATE()=1），后续COMMIT会导致部分数据提交，破坏原子性。
SQL Server 存储过程里事务不会自动回滚，除非你明确开启 SET XACT_ABORT ON 并触发足够严重的错误——默认行为是“只中断当前语句，事务继续挂着”，这是数据不一致的高发源头。
为什么约束错误（如主键冲突）不触发回滚？
默认 XACT_ABORT = OFF 时，违反 UNIQUE、CHECK 或外键约束只会让那一条 INSERT 或 UPDATE 失败，后续语句照常执行。事务仍处于活动状态（XACT_STATE() = 1），如果后面跟了 COMMIT，前面成功写的部分就永久落库了。
- 错误示例：
INSERT INTO users(id, name) VALUES (1, 'a'); INSERT INTO users(id, name) VALUES (1, 'b');—— 第二条报错，但第一条已生效 - 验证方式：
SELECT XACT_STATE()在错误后执行，返回1就说明事务还开着 - 真正可靠的应对：开头加
SET XACT_ABORT ON，这样约束错误会直接终止整个批处理，并把事务置为不可提交状态（XACT_STATE() = -1）
TRY…CATCH 本身不等于事务回滚
很多人以为进了 CATCH 块就万事大吉，其实它只是捕获错误，不自动清理事务。如果你在 CATCH 里没写 ROLLBACK TRANSACTION，或者没判断 XACT_STATE()，事务照样挂着。
- 必须检查
XACT_STATE()：IF XACT_STATE() 0 ROLLBACK TRANSACTION——-1表示已损坏必须回滚，1表示可回滚但需手动执行 - 别依赖
@@TRANCOUNT判断是否该回滚，它在某些错误下会失真；XACT_STATE()才是唯一权威依据 -
THROW在CATCH里重抛错误前，务必先回滚，否则调用方可能误判为“成功”
存储过程内部 BEGIN TRANSACTION 是个陷阱
在被调用的存储过程中自己写 BEGIN TRANSACTION，很容易破坏外层事务一致性，导致错误 266（事务计数不匹配）。
- 根本原则：事务边界由最外层调用者控制，存储过程只负责业务逻辑
- 如果过程需要局部回滚（比如注册用户+发邮件，发邮件失败不想删用户），用
SAVE TRANSACTION @sp_name+ROLLBACK TO @sp_name，而不是另起事务 - 过程内执行 DDL（如
ALTER PROCEDURE）会隐式提交，前面所有 DML 立刻固化，再也无法回滚
MySQL 和 PostgreSQL 的行为差异更隐蔽
它们不共享 SQL Server 的 XACT_ABORT 机制，但各自有等效陷阱：
- MySQL：
DECLARE HANDLER FOR SQLEXCEPTION只跳转，不回滚、不提交——你必须在 handler 里显式写ROLLBACK或COMMIT，且要确认当前autocommit状态 - PostgreSQL：一旦异常进入
EXCEPTION块，整个事务块即失效，后续任何 DML 都报current transaction is aborted；想局部恢复，只能靠SAVEPOINT+ROLLBACK TO - 共性坑：所有数据库里，触发器里的
RAISERROR/THROW/SIGNAL都不会自动回滚主事务，必须配对ROLLBACK TRANSACTION
真正容易被忽略的是：事务是否“真结束了”，不能只看有没有报错，得查 XACT_STATE()（SQL Server）、INFORMATION_SCHEMA.INNODB_TRX（MySQL）或 pg_stat_activity（PostgreSQL）——很多线上故障，都是因为回滚语句执行了，但事务状态没清干净，连接卡在 idle in transaction。
