触发器不开启新事务，运行在父语句事务上下文中；任一语句失败（如signal、外键冲突）均导致整个事务回滚，但仅限innodb表，myisam、跨库写入或外部操作不受保护。
触发器本身不开启新事务，它运行在父语句的事务上下文中
这是最常被误解的前提：触发器不是独立事务单元。你执行 INSERT INTO orders，哪怕触发器里又执行了 UPDATE inventory，整个操作仍属于同一个事务。只要任一语句失败（比如外键冲突、类型错误、或你主动 SIGNAL），整个事务回滚——包括原始 DML 和触发器内所有修改。
但陷阱在于：如果触发器里操作的是非事务引擎表（如 MyISAM）、调用了不可回滚的外部动作（如写文件、发 HTTP 请求），或更新了另一数据库的表，这部分就脱离了事务保护。InnoDB 表是底线要求，别在触发器里碰 MyISAM 或 MEMORY 表。
- 用
SHOW CREATE TABLE table_name确认表引擎是InnoDB - 避免在触发器中调用存储过程，除非该过程内部也严格只操作 InnoDB 表且无副作用
-
AFTER触发器里不要做INSERT INTO remote_db.table—— 这类跨库写入无法回滚
校验失败必须显式中断事务，不能静默修复或仅记日志
很多人以为“触发器执行了”就等于“一致性被保障了”，其实不然。如果校验逻辑发现订单总金额与明细和不等，却只往 error_log 表里插一条记录，主事务照样提交，数据已错。
真正起作用的是让数据库立刻报错并终止当前事务：
- MySQL 5.5+：用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'total mismatch' - PostgreSQL：用
RAISE EXCEPTION 'total mismatch' - SQL Server：用
THROW 50000, 'total mismatch', 1 - 绝对不要用
INSERT INTO audit_log、PRINT或RAISE NOTICE替代报错
并发更新时必须加锁，否则计算类校验必然出错
比如订单明细变更后重算总金额，若触发器只写 SELECT SUM(amount) FROM order_items WHERE order_id = NEW.order_id，不加锁，就会出现两个事务同时读到旧值、各自计算、先后写入，最终丢失一次更新。
解决方法不是“让触发器更聪明”，而是明确告诉数据库：“我要基于当前一致快照做计算”：
- PostgreSQL / MySQL（InnoDB）：在触发器内用
SELECT ... FOR UPDATE锁定被汇总的主记录（如orders表对应行） - 锁范围要精准——只锁目标订单，别锁全表；WHERE 条件必须能命中索引
- 避免在触发器里查大表（如
SELECT * FROM big_history WHERE user_id = NEW.user_id），锁等待和扫描开销会直接拖垮吞吐
跨表联动容易引发递归或死锁，单向依赖 + 显式标记是唯一安全路径
典型场景：用户登录更新 user_profiles.last_login_time，触发器同步改 users.last_login_time；而 users 表上又有触发器反向更新 user_profiles —— MySQL 直接报错 ERROR 1442，PostgreSQL 可能卡死。
根本解法不是“禁用一个触发器”，而是设计时就切断循环：
- 只在源头表建触发器（如仅在
user_profiles上建AFTER UPDATE），目标表users不设任何触发器 - 如果业务真需要双向同步，改用应用层统一写入口，或通过
tx_outbox表 + 异步服务驱动 - 绝不允许触发器内执行
UPDATE同一表（除非带严格条件拦截，且确认不会触发自身）
真正难的不是写对一行 SIGNAL，而是判断这个逻辑是否真该放在触发器里——多数时候，它只是个昂贵的幻觉。
