触发器内禁止显式事务控制，应仅执行DML操作；余额校验与扣减宜用BEFORE触发器，流水记录用AFTER触发器并防递归；并发超扣需原子更新或行锁；核心资金逻辑应移至应用层或存储过程。
触发器里不能用 COMMIT 或 BEGIN TRANSACTION
直接在触发器中执行 UPDATE 扣减余额 + INSERT 流水，看起来很顺，但若触发器内显式调用 COMMIT 或嵌套事务，多数数据库（如 MySQL、PostgreSQL）会报错：Trigger cannot contain explicit COMMIT。触发器天然运行在父事务上下文中，它的所有操作自动跟随外层事务的提交或回滚——这点必须先确认，否则后续逻辑全错。
- MySQL 8.0+ 和 PostgreSQL 都禁止触发器内使用
COMMIT、ROLLBACK、START TRANSACTION - SQL Server 允许触发器内写事务控制语句，但极不推荐：它会让事务嵌套变得不可预测，尤其配合应用层事务时容易死锁或丢失回滚
- 真正安全的做法是：只做 DML（
UPDATE/INSERT），把事务控制完全交给应用或存储过程
BEFORE INSERT 触发器更适合扣减校验
假设用户下单要扣虚拟币，且必须“先检查余额是否足够，再扣减”，这时用 BEFORE INSERT 比 AFTER INSERT 更稳妥。它能在插入订单记录前拦截非法操作，并通过 RAISE_ERROR（SQL Server/PostgreSQL）或 SIGNAL（MySQL）中止整个语句。
DELIMITER $$
CREATE TRIGGER check_balance_before_order
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE cur_balance DECIMAL(12,2);
SELECT balance INTO cur_balance FROM users WHERE id = NEW.user_id;
IF cur_balance
- 注意顺序：先查余额，再更新，避免并发下超扣（仍需加行锁或乐观锁补救）
- MySQL 中
SIGNAL是唯一能主动报错中断的方式；PostgreSQL 用RAISE EXCEPTION；SQL Server 用THROW - 这个触发器同时完成校验 + 扣减，但流水记录没写——因为
BEFORE里还拿不到自增主键，不适合生成关联流水
AFTER INSERT 触发器补流水，但得小心循环触发
流水表（比如 transactions）通常需要记录操作时间、来源单号、变动金额等，这些字段往往依赖原表的主键或默认值。所以扣减后立刻写流水，应选 AFTER INSERT 触发器，但必须关掉递归触发，否则插入流水又触发自身，无限循环。
- MySQL：设置
SET GLOBAL log_bin_trust_function_creators = 1不够，关键是确保触发器不修改被监听的同一张表（比如不要在orders的触发器里再去UPDATE orders） - PostgreSQL：默认禁用递归触发，但若触发器里调用了函数又间接修改了原表，仍可能触发；用
pg_trigger_depth()判断深度更保险 - SQL Server：在触发器开头加
IF TRIGGER_NESTLEVEL() > 1 RETURN是常用防御手段 - 流水表的
order_id字段可以直接用NEW.id（MySQL/PG）或INSERTED.id（SQL Server）赋值
并发场景下余额扣减会超卖，得加锁或改用原子操作
多个请求同时触发同一个用户的扣减触发器，查余额 → 扣减两步非原子，大概率导致余额扣成负数。这不是触发器写法问题，而是逻辑缺陷。
- 最简方案：在
UPDATE users语句里加上条件判断，例如UPDATE users SET balance = balance - 10 WHERE id = 123 AND balance >= 10，然后检查ROW_COUNT()是否为 1 - 进阶方案：对用户行加
SELECT ... FOR UPDATE（InnoDB）或SELECT ... FOR NO KEY UPDATE（PG），但要注意锁范围和持有时间 - 终极建议：别依赖触发器做核心资金逻辑。把它当“辅助日志”用，把余额校验和扣减移到应用层或存储过程中统一控制，触发器只负责补流水
触发器适合旁路记录、简单约束、审计留痕；一旦涉及资金一致性、多表联动、复杂分支，它就不再是首选工具——不是不会写，而是难测、难调、难维护。
