触发器内执行ROLLBACK会无条件终止整个外部事务；应改用RAISERROR（SQL Server）或SIGNAL（MySQL）抛错，由上层存储过程通过保存点控制回滚范围。
在SQL触发器里直接执行 ROLLBACK 会无条件终止整个外部事务——包括调用它的存储过程、原始DML语句，以及所有已执行的触发器逻辑。这不是“不影响”，而是“必然影响”。想隔离回滚范围，必须放弃显式 ROLLBACK，改用更可控的机制。
触发器内不能用 ROLLBACK 的根本原因
SQL Server 和 MySQL 都不支持触发器内安全地提交或回滚局部事务。原因很实在：
-
ROLLBACK TRANSACTION在触发器中总是回滚最外层事务，不是“当前触发器这一段”，而是从BEGIN TRANSACTION开始的所有操作 - MySQL 根本禁止在触发器中写
ROLLBACK，语法直接报错：ERROR 1305 (42000): SAVEPOINT, ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT, and ROLLBACK are not allowed in stored functions or triggers - SQL Server 允许写，但效果等同于“炸掉整条流水线”：后续同一批语句（比如批量
INSERT中的第3行）直接跳过，不会继续处理 - 即使你加了
SAVE TRANSACTION sp_name，触发器里也无法用ROLLBACK TO sp_name—— 因为保存点作用域不跨触发器边界
替代方案：用错误中断代替主动回滚
让触发器“失败”，而不是“回滚”，把控制权交还给上层。这是最干净、最兼容的做法：
- SQL Server：用
RAISERROR('Invalid status', 16, 1)或THROW 50000, 'Invalid status', 1抛出用户错误；调用方（存储过程）捕获后决定是否ROLLBACK - MySQL：必须用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status'；RAISERROR不可用，且不能用自定义错误号低于 5000 的值 - 关键点：这些语句本身就会导致当前语句终止，并使宿主事务进入“不可提交”状态（
XACT_STATE() = -1），后续COMMIT失败，只有ROLLBACK有效 - 不要在触发器里写
TRY...CATCH或DECLARE EXIT HANDLER来吞掉错误——这会让问题静默，掩盖数据不一致风险
存储过程必须自己管理事务边界
触发器没有独立事务能力，所以事务控制责任必须落在调用方身上：
- 存储过程开头必须显式写
BEGIN TRANSACTION（SQL Server）或START TRANSACTION（MySQL），不能依赖隐式事务 - 执行可能触发异常的 DML 前，先设保存点：
SAVE TRANSACTION sp_before_insert（SQL Server）或SAVEPOINT sp_before_insert（MySQL） - 如果触发器抛错，存储过程在
CATCH或EXIT HANDLER里做ROLLBACK TO sp_before_insert，只撤回本次操作，保留之前已完成步骤 - 注意：MySQL 的
SAVEPOINT在触发器执行期间仍有效，但不能在触发器里创建或释放它
真正容易被忽略的是：触发器里的任何阻塞（比如查一张被锁住的表）、超时、死锁，都会让整个外部事务卡住或失败——它不是代码问题，是事务模型决定的刚性约束。别试图在触发器里“兜底”，把它当成一道不可绕过的闸门，让上层来决定开还是关。
