RAISERROR不会自动回滚事务，必须显式执行ROLLBACK TRANSACTION或使用THROW配合SET XACT_ABORT ON才能确保事务终止。
触发器里 RAISERROR 不会自动回滚事务
SQL Server 触发器中调用 RAISERROR，只是抛出错误，并不等价于事务回滚。如果没显式写 ROLLBACK TRANSACTION，上层语句（比如 INSERT/UPDATE）仍可能提交成功，数据状态和预期严重不符。
常见错误现象：RAISERROR('校验失败', 16, 1) 执行后，错误信息出现在 SSMS，但表里新数据已经插入；或者触发器报错，但主事务继续执行后续语句。
- 必须在
RAISERROR前或后紧跟ROLLBACK TRANSACTION，且要确保它一定会执行（比如放在BEGIN TRY...END TRY外，或用IF @@ERROR 0判断后处理） - 推荐统一用
THROW（SQL Server 2012+），它默认终止当前批处理，配合SET XACT_ABORT ON能更可靠中断事务 -
RAISERROR的严重级别必须 ≥ 11 才能被客户端捕获；级别 10 及以下仅当WITH LOG才写入错误日志，且不会中断执行流
触发器中如何安全判断并回滚当前事务
触发器运行在外部 DML 语句的事务上下文中，没有独立事务。所以不能用 BEGIN TRANSACTION 开启新事务，而要检查 @@TRANCOUNT 并回滚最外层事务。
使用场景：比如禁止周末插入订单，校验失败时必须撤回整个 INSERT 操作。
- 先用
IF @@TRANCOUNT > 0确认有活跃事务，再执行ROLLBACK TRANSACTION - 避免在
TRY...CATCH块里只RAISERROR而不ROLLBACK——CATCH块内不回滚，事务依然挂起，容易引发阻塞或脏数据 - 若触发器嵌套（比如 A 触发器修改另一张表，又激活 B 触发器），
@@TRANCOUNT会累加，ROLLBACK一次即可回滚到最外层起点
IF NOT (DATEPART(WEEKDAY, GETDATE()) IN (1,7))
BEGIN
RAISERROR('仅允许在周末创建订单', 16, 1);
ROLLBACK TRANSACTION;
RETURN;
END
RAISERROR 和 THROW 在事务控制上的关键差异
RAISERROR 是“抛错但不管事务”，THROW 是“抛错并默认中断执行流”，二者行为边界非常影响回滚可靠性。
参数差异明显：RAISERROR 需手动指定严重级、状态值；THROW 不需要，且会保留原始错误号、行号、过程名。
-
THROW后语句不再执行（类似断点），天然适配事务中断逻辑；RAISERROR后代码继续跑，极易漏掉ROLLBACK - 使用
THROW前必须确保SET XACT_ABORT ON已启用，否则某些错误（如约束冲突）仍可能让事务半途而废 - 兼容性注意：SQL Server 2005–2008R2 只支持
RAISERROR；2012+ 推荐优先用THROW，语义更清晰
为什么 SET XACT_ABORT ON 是隐性刚需
即使写了 ROLLBACK TRANSACTION，如果没开 SET XACT_ABORT ON，某些运行时错误（比如主键冲突、类型转换失败）会导致触发器退出，但外部事务不自动回滚，最终提交部分更改。
性能影响几乎为零，但兼容性和健壮性提升巨大 —— 它强制 SQL Server 在任何未捕获错误发生时回滚整个事务。
- 必须在触发器开头就设置：
SET XACT_ABORT ON，不能依赖会话级默认值 - 该设置作用域是当前批处理，触发器内生效；但不会影响调用它的存储过程是否开启该选项
- 不开它，
THROW在某些错误场景下也无法保证事务终止，属于容易被忽略的底层开关
SET XACT_ABORT ON 这一行，以及误以为 RAISERROR 自带回滚能力。 
