mysql触发器不能使用begin...end套事务控制语句，因其运行在父语句事务上下文中，不支持start transaction、commit、rollback；唯一可控回滚方式是signal抛异常，使整个语句失败并回滚。
触发器里不能用 BEGIN...END 套事务控制语句
MySQL 触发器本身不支持显式开启或提交事务，START TRANSACTION、COMMIT、ROLLBACK 在触发器体内直接写会报错：ERROR 1305 (42000): FUNCTION does not exist（实际是语法错误，但报错容易误导）。这是因为触发器运行在父语句的事务上下文中，它不是独立事务单元。
常见错误现象：有人把存储过程那套搬进来，在触发器里写 START TRANSACTION，结果建触发器失败；或者误以为加个 IF ... THEN ROLLBACK; 就能中断主操作——其实根本无效。
-
ROLLBACK在触发器里不是语法错误，但执行时会被忽略（除非触发器本身在XA或外部事务中异常退出） - 真正能影响主语句的是
SIGNAL：抛出异常可让整个语句回滚（前提是主连接没禁用自动回滚） - 所有对表的修改（
INSERT/UPDATE/DELETE）都和主语句共用同一事务，成功与否取决于主语句最终是否提交
BEFORE 和 AFTER 触发器对事务行为的影响差异
两者都不开启新事务，但时机不同导致副作用明显不同：
-
BEFORE触发器可以修改NEW行数据（比如补默认值、校验字段），这些变更会进入主语句的写入内容；若此时用SIGNAL抛错，主语句直接终止，无任何写入 -
AFTER触发器无法修改当前行（NEW只读），但可以安全操作其他表；如果这里出错（比如插入日志表失败），主语句已执行完，但整个事务仍会回滚——前提是错误未被HANDLER捕获且 MySQL 配置了autocommit=0或显式事务包裹 - 跨库操作（比如
AFTER INSERT写另一数据库的表）失败时，回滚行为依赖存储引擎：InnoDB 支持，MyISAM 不支持事务，会导致数据不一致
想实现“条件性回滚”？靠 SIGNAL + 主动检查
触发器没法自己决定回滚，但可以通过抛异常把控制权交还给上层。这要求主逻辑必须在事务块中运行，并接受错误传播。
示例场景：订单插入前检查库存，不足则拒绝：
DELIMITER $$
CREATE TRIGGER check_stock_before_order
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
DECLARE stock_left INT DEFAULT 0;
SELECT quantity INTO stock_left
FROM products WHERE id = NEW.product_id;
IF stock_left
- 这个
SIGNAL不会单独回滚触发器，而是让整个INSERT失败，从而回滚所有已做的变更（包括触发器内可能发生的UPDATE） - 如果主语句是单条
INSERT且autocommit=1，失败即回滚；但如果是在BEGIN...COMMIT块里，也一样生效 - 别用
SELECT ... INTO查大量数据——触发器执行路径要快，否则拖慢主语句，尤其高并发写入时
嵌套触发器 + 多表联动时最容易漏掉的坑
一个触发器改表 A，表 A 的触发器又改表 B……这种链式调用看似灵活，实则危险：
- MySQL 默认允许最多 15 层嵌套触发器（由
max_sp_recursion_depth控制），超限直接报错ERROR 1456 (HY000) - 每层都可能抛
SIGNAL，但错误堆栈不清晰，调试时很难定位是哪一层崩的 - 如果某中间表用了 MyISAM 引擎，前面 InnoDB 表的修改已落盘，后面失败也无法回滚，造成脏数据
- 复制环境（如主从）下，触发器默认不记录到 binlog（
log_bin_trust_function_creators=0时更严格），从库可能缺失逻辑
复杂业务逻辑真需要多步校验或补偿，别硬塞进触发器——用应用层事务 + 幂等接口更可控。触发器只做轻量、确定、原子的动作，比如生成 UUID、更新时间戳、简单计数器增减。
