MySQL触发器中禁止COMMIT等事务语句，因其无独立事务上下文，所有操作自动加入主DML事务；解析阶段即拦截，报ERROR 1422，正确做法是用SIGNAL中断整个事务。
MySQL触发器里写 COMMIT 会直接报错，不是语法写错了，也不是权限问题，而是内核级禁止——它根本没给你留事务出口。
ERROR 1422 是解析阶段就拦截，不是运行时报错
只要触发器定义中出现 COMMIT、ROLLBACK、START TRANSACTION，哪怕包在 IF FALSE THEN COMMIT; END IF; 里，MySQL 在 CREATE TRIGGER 时就会拒绝，报 ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger。这不是执行时才检查，所以堆栈里找不到具体哪一行出问题。
常见误触点包括：
-
TRUNCATE TABLE、ALTER TABLE、DROP INDEX这类 DDL 语句会隐式提交，同样触发ERROR 1422 - 调用的存储过程中含
COMMIT，即使触发器本身没写，建触发器时也会失败 -
SAVEPOINT是唯一允许的事务控制语句，但它只能用于局部回滚，不能替代COMMIT
触发器没有独立事务上下文，所有操作自动加入主事务
触发器不是“子事务”，它和引发它的那条 INSERT/UPDATE/DELETE 共享同一个事务 ID、undo log 和隔离快照。你在 AFTER INSERT 里往 audit_log 插一条记录，这条记录是否落盘，完全取决于主语句最终是 COMMIT 还是 ROLLBACK。
这意味着：
- 主语句失败（比如被
SIGNAL中断），整个事务回滚，包括触发器里的所有变更 - 触发器里执行
SELECT ... FOR UPDATE可能引发死锁，尤其跨多表时 - 对临时表（
TEMPORARY TABLE）的操作不受主事务影响，但普通表全部参与
校验失败时别写 ROLLBACK，改用 SIGNAL 抛异常
很多人想在校验失败时“只撤回触发器动作”，于是写 ROLLBACK，结果报 ERROR 1305 (42000): FUNCTION does not exist——这其实是 MySQL 拦截非法语句的伪装错误，并非真缺函数。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
正确做法是中断整个父事务：
IF NEW.amount < 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount cannot be negative'; END IF;
这样主语句会失败，MySQL 自动回滚全部操作（含触发器内已执行的语句）。不需要你手动干预事务边界。
需要持久化日志或发通知？别硬塞进触发器
如果业务确实需要在主事务外独立落库（比如审计日志、异步通知），触发器不是合适载体。原因很实际：
- 自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）是 Oracle 的机制，MySQL 不支持 - 在触发器里调用
UTL_HTTP.request或写文件等外部操作，ROLLBACK对其完全无效，反而制造不一致 - 耗时操作（如远程 HTTP 请求、复杂计算）会拖慢主 DML，且无法被事务回滚
更稳妥的做法是：把这类逻辑移到应用层，或用消息队列解耦；若必须数据库内处理，考虑用事件调度器（EVENT）+ 状态标记表，避开触发器的事务绑定限制。
真正容易被忽略的是：触发器里对 NEW.col 赋值后，如果该列有 NOT NULL 约束和默认值，在非严格模式下会静默转为默认值而非报错——这个行为不会触发二次约束校验，调试时极难察觉。
