mysql触发器内禁止任何显式或隐式事务控制语句，包括commit、rollback等，因其必须依附于父dml的隐式事务；需用signal抛异常实现回滚，且仅限before触发器；长事务逻辑应移交应用层统一管理。
MySQL触发器里写COMMIT直接报ERROR 1422
这不是权限或语法写错，是MySQL内核级硬性限制：触发器必须运行在父DML语句开启的隐式事务中，它没有自己的事务边界。只要触发器定义或调用链中出现COMMIT、ROLLBACK、START TRANSACTION、TRUNCATE TABLE、ALTER TABLE，甚至只是存储过程里有这些语句，建触发器就会失败，报ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。
常见踩坑点包括：
-
IF NEW.status = 'invalid' THEN ROLLBACK; END IF;——MySQL根本不认这句，解析阶段就拒了 - 触发器里
CALL log_proc()，而log_proc内部含COMMIT——错误堆栈不指明具体位置，只提示“trigger context violation” - 以为
BEGIN ... END块能隔离事务控制语句，其实只要语法树里存在COMMIT关键字，就过不了解析
想中断主操作？用SIGNAL，别用ROLLBACK
校验失败时，很多人想“只回滚触发器里的动作”，于是写ROLLBACK，结果报ERROR 1305 (42000): FUNCTION does not exist——这是MySQL拦截非法事务语句后给出的误导性提示。
正确做法是用SIGNAL抛异常，让整个父事务自动回滚：
IF NEW.amount <p>注意几个关键点：</p>
- 必须放在
BEFORE INSERT/UPDATE/DELETE触发器中；AFTER里SIGNAL无效，因为数据已落库 - 别在
SIGNAL前执行副作用操作（比如发HTTP请求、写普通日志表），这些不会随事务回滚，可能留下脏状态 - 如果真要记错误日志又不想破坏事务一致性，可改用
BLACKHOLE或ARCHIVE引擎的表，它们不参与事务
长事务不能靠触发器扛，得交给应用层
触发器天然不适合处理耗时、跨系统、带外部依赖的操作。哪怕只是往另一张表INSERT一条审计日志，若该表没索引或锁竞争激烈，整个主INSERT都会被拖住——这不是代码问题，是事务设计决定的。
真正需要长事务逻辑（如订单创建+库存扣减+积分更新+通知推送）时，应该：
- 禁用相关表的业务触发器，把逻辑收归到应用层统一事务管理
- 用应用代码显式控制
BEGIN TRANSACTION→ 多步DML →COMMIT/ROLLBACK - 对必须异步的非数据库操作（如发邮件、调API），改用消息队列解耦，由独立消费者执行，并通过幂等+补偿机制保证最终一致性
- 若仍需数据库侧轻量记录，可用
INSERT INTO audit_log () VALUES ()配合DELAYED（MySQL 5.7-）或INSERT ... ON DUPLICATE KEY UPDATE降低阻塞风险
SQL Server和Oracle的替代思路不通用
SQL Server允许在触发器里写ROLLBACK TRANSACTION，但它会清空整个外层事务（@@TRANCOUNT归零），容易引发Error 3609或Error 266；Oracle支持PRAGMA AUTONOMOUS_TRANSACTION开独立事务，但自治事务看不到主事务未提交的数据，且父子事务完全解耦——主事务回滚不影响它，日志可能留下而主数据没写入。
MySQL没有等价机制。云数据库（阿里云RDS、腾讯云CDB）也继承这一限制。别指望“绕过”，更别试SAVEPOINT来模拟局部提交——它只能ROLLBACK TO，不能COMMIT，且无法脱离外层事务生效。
最容易被忽略的一点是：触发器不是执行单元，而是语句钩子。它的成败，本质上是你对事务边界的理解是否清晰——主语句一提交，触发器就结束了；主语句一回滚，它连同所有副作用一起消失。想留痕？先想清楚哪些操作真的该进事务，哪些不该。
