MySQL触发器中禁止COMMIT，因其会破坏事务原子性；内核在解析阶段即拦截所有显式或隐式提交操作（如COMMIT、TRUNCATE、CALL含事务的存储过程），报ERROR 1422，必须用SIGNAL中断整个事务。
MySQL触发器里写COMMIT直接报ERROR 1422
不是语法写错，也不是权限问题，而是MySQL内核在解析阶段就拦截——只要触发器定义中出现COMMIT关键字（哪怕包在IF FALSE THEN COMMIT; END IF;里），CREATE TRIGGER就会失败。错误信息固定是：ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。这不是执行时报错，所以堆栈里看不到具体哪一行，只提示“上下文违规”。
触发器根本没有自己的事务上下文
触发器不是独立事务单元，它必须依附于触发它的那条INSERT/UPDATE/DELETE语句所开启的事务。这个事务可能是显式的（START TRANSACTION包裹），也可能是隐式的（autocommit=1时自动开启）。所有触发器内的操作——包括往日志表INSERT、更新计数器——都共享同一个事务ID、同一份undo log和隔离快照。
-
COMMIT会试图提前结束这个外部事务，破坏原子性：比如触发器先写了一条审计日志并COMMIT，主语句后续因外键约束失败而回滚，结果日志留下、主表为空，数据不一致 -
ROLLBACK同样被禁止，不是功能缺失，而是设计上不允许干预事务边界 - 连
SAVEPOINT都只允许用，但ROLLBACK TO SAVEPOINT仍会触发ERROR 1422
看似安全的操作，其实一碰就崩
很多错误不是触发器本身写的COMMIT，而是间接引入的：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 触发器里
CALL p()，而存储过程p里有START TRANSACTION→ 创建触发器就失败 - 触发器中执行
TRUNCATE TABLE audit_log→ DDL隐式提交，照样触发ERROR 1422 - 调用的存储过程中对
MyISAM表做INSERT→ MyISAM无事务，操作即刻生效，等同于隐式提交 - 在触发器里
SELECT ... FOR UPDATE后再更新另一张表 → 可能引发锁等待超时，但错误堆栈不体现根源
校验失败时该怎么做：用SIGNAL中断整个事务
想阻止非法数据入库？别碰ROLLBACK，改用SIGNAL抛异常，让MySQL自动回滚全部变更（包括主语句和触发器已执行的操作）：
IF NEW.amount < 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount cannot be negative'; END IF;
注意：SIGNAL只在MySQL 5.5+支持；AFTER触发器中用SIGNAL已无意义（数据早已落盘）；错误常藏在被调用的存储过程中，调试时优先运行SHOW ERRORS LIMIT 1，再分段模拟NEW/OLD值。
真正容易被忽略的是：非DML操作（如调用xp_cmdshell、写文件、发HTTP请求）压根不在事务保护范围内，ROLLBACK对其完全无效；而触发器里哪怕只做一次SELECT FOR UPDATE，也可能隐式提交当前事务。
