MySQL触发器无独立事务，完全依附主事务，主事务回滚则触发器操作一并撤销；其SQL与原语句共享事务ID、undo log和隔离快照，且禁止执行COMMIT/ROLLBACK。
MySQL触发器没有独立事务，它完全依附于主事务；一旦主事务回滚，触发器里做的所有操作都会被一并撤销。
触发器运行在主事务上下文内
MySQL的BEFORE和AFTER触发器不是“另起炉灶”的独立执行单元。它们在引发它的那条INSERT/UPDATE/DELETE语句所处的事务中直接运行——也就是说，触发器体内的SQL（比如INSERT INTO log_table）和原语句共享同一个事务ID、同一个undo log、同一个隔离快照。
常见错误现象：
你在AFTER INSERT里写了一条UPDATE counter_table SET total = total + 1，然后主事务因下游校验失败而ROLLBACK，结果发现counter_table的值没变——不是触发器没执行，而是它执行了，又被回滚了。
- 触发器无法调用
COMMIT或ROLLBACK（会报错ERROR 1305 (42000): SAVEPOINT does not exist） - 触发器中对临时表（
TEMPORARY TABLE）的操作不受主事务影响，但对普通表的操作全部参与主事务 - 如果触发器里执行了DDL（如
ALTER TABLE），会隐式触发主事务提交，导致前面所有DML立刻落盘——这是极危险的意外行为
为什么sys_exec调用的PHP脚本看不到新插入的数据
当你在触发器里用sys_exec('php query.php')去查刚插入的记录，得到的是旧数据，根本原因不是PHP慢或延迟，而是：该PHP进程建立的是全新数据库连接，开启的是全新事务，按默认REPEATABLE READ隔离级别，它读不到主事务中尚未提交的变更。
使用场景：
想在插入工单glpi_tickets后，立刻通知外部系统最新ID。硬要在触发器里调外部脚本，就必然面临这个隔离墙。
- 解决思路不是“等提交”，而是把ID作为参数传出去：
sys_exec(CONCAT('php query.php ', NEW.id)) - 避免在触发器中做任何依赖“当前事务可见性”的查询（如
SELECT MAX(id)） -
sys_exec本身是不可靠机制：超时、权限、路径错误都会让触发器静默失败，且不中断主事务
替代方案：绕过触发器事务绑定的常用做法
真需要“事务提交后才执行”的逻辑，MySQL原生不支持，得靠应用层或架构设计补位。
- 应用代码在
INSERT后显式COMMIT，再立即执行后续动作（发消息、调API、更新缓存） - 用消息队列解耦：主事务成功后发一条MQ消息，由消费者处理后续逻辑，天然具备最终一致性
- 定时扫描+状态机：给主表加一个
status字段（如'pending_notify'），由后台任务定期捞出并处理，处理完再更新为'notified' - 不要用触发器做跨系统协作——它适合数据完整性检查、审计日志、字段自动填充这类纯库内操作
最易被忽略的一点：很多人以为AFTER INSERT意味着“已经落地”，其实它只是“语句执行完”，离真正持久化（COMMIT）还隔着一层事务控制权。只要还没COMMIT，整个链条都可能被回滚，包括你认为“已经发生”的触发器动作。
