MySQL和PostgreSQL触发器中禁止使用COMMIT、ROLLBACK、BEGIN TRANSACTION等事务控制语句，因其必须依附外层事务上下文，强行提交会破坏原子性并报ERROR 1422；正确做法是仅执行DML操作，由应用层或存储过程统一控制事务边界。
触发器里不能用 COMMIT 或 BEGIN TRANSACTION
MySQL 和 PostgreSQL 的触发器中，COMMIT、ROLLBACK、BEGIN TRANSACTION 都是非法操作，强行写会导致 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。主从状态联动必须在事务上下文内完成，靠外层业务事务兜底，触发器只负责“修改数据”，不负责“结束事务”。
- 正确做法：在触发器中仅执行
UPDATE/INSERT/DELETE，由调用方（如应用层或存储过程）控制事务边界 - 常见踩坑：在触发器里调用含
COMMIT的存储过程，或误以为“更新完从表就要立刻落盘”，结果触发器直接报错退出 - PostgreSQL 还额外禁止在
AFTER触发器中修改被触发的同一张表（会引发递归或无限循环），需用BEFORE或改用DEFERRABLE约束替代
主表 UPDATE 时如何安全更新从表 status 字段
典型场景：订单主表 orders 的 status 变为 'shipped'，需同步将关联的 order_items 表所有行设为 delivered = true。关键在于避免子查询引用被修改行导致的不确定性。
- MySQL 中，
BEFORE UPDATE触发器可安全读取OLD.status和NEW.status，但不能在AFTER触发器中依赖SELECT ... FROM orders WHERE id = NEW.id—— 此时该行可能尚未持久化，值不可靠 - 推荐写法：在
BEFORE UPDATE中直接UPDATE order_items SET delivered = true WHERE order_id = OLD.id AND OLD.status != 'shipped' AND NEW.status = 'shipped' - 务必加条件判断（如
OLD.status != NEW.status），否则每次更新都无差别刷从表，浪费 I/O 且易引发并发冲突
INSERT/DELETE 也要覆盖，否则状态会不一致
只处理 UPDATE 是最常见疏漏。例如主表新增一条 status = 'canceled' 订单，若没对应触发器初始化从表的 canceled_at 字段，后续逻辑就可能误判该订单仍有效。
-
INSERT触发器：应根据NEW.status初始化从表对应字段，比如INSERT INTO order_items (order_id, canceled_at) SELECT NEW.id, NOW() WHERE NEW.status = 'canceled' -
DELETE触发器：慎用。多数情况应走软删（is_deleted = 1），因为硬删后无法回溯主表原始状态，从表联动失去依据；若必须硬删，请确保从表也级联删除，而非仅更新状态 - 三者触发器需共用统一的状态映射逻辑（如
'paid' → 'locked'），建议抽成函数（MySQL 的FUNCTION或 PostgreSQL 的FUNCTION），避免硬编码散落各处
性能瓶颈往往出在未加索引的 JOIN 条件上
触发器里常见的 UPDATE order_items SET ... WHERE order_id = OLD.id，如果 order_items.order_id 没有索引，单次主表更新可能拖慢整个事务达数百毫秒，尤其在高并发下单场景。
- 检查方式：
SHOW INDEX FROM order_items，确认order_id列存在KEY类型索引（非FULLTEXT或SPATIAL） - 复合场景（如按
order_id + status更新）需建联合索引：CREATE INDEX idx_order_status ON order_items(order_id, status) - PostgreSQL 用户注意：
BEFORE ROW触发器中不能用RETURN NULL阻止插入却保留主键自增，这会导致 ID 浪费；不如用CHECK约束提前拦截非法状态
EXPLAIN 跑一遍触发器内的每条 DML，看是否命中索引。没有索引的触发器，上线就是定时抖动源。 
