MySQL触发器禁止显式或隐式事务控制，CREATE TRIGGER时即报ERROR 1422；触发器共享主事务上下文，无法局部提交；校验应使用BEFORE触发器+ SIGNAL抛异常，而非ROLLBACK。
MySQL触发器里写 COMMIT 或 ROLLBACK 会直接报错，不是语法写错了，而是数据库内核在解析阶段就禁止——它根本不允许触发器拥有事务控制权。
ERROR 1422 是解析时报错，不是运行时报错
只要触发器定义里出现 COMMIT、ROLLBACK、START TRANSACTION，甚至只是被调用的存储过程中包含这些语句，MySQL 就会在 CREATE TRIGGER 阶段拒绝创建，报 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。
常见误判点：
- 以为
IF FALSE THEN COMMIT; END IF;能绕过——不行，解析器不执行逻辑判断，只扫描语法树 - 把
TRUNCATE TABLE当成普通 DML——它是 DDL，会隐式提交，同样触发 ERROR 1422 - 调用了一个看似“干净”的存储过程，结果它内部有
CREATE TEMPORARY TABLE——这也算隐式提交
触发器没有自己的事务上下文，只有主事务的影子
触发器不是独立事务单元，它和引发它的那条 INSERT/UPDATE/DELETE 共享同一个事务 ID、同一份 undo log、同一个隔离快照。你在 AFTER INSERT 里往日志表插了一行，这行数据是否落盘，完全取决于主语句最终是 COMMIT 还是 ROLLBACK。
这意味着：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 你不能靠触发器“局部提交”审计日志，指望它逃过主事务回滚——不可能
-
SELECT ... FOR UPDATE在触发器里执行，可能因锁冲突报ERROR 1205或ERROR 1442，而不是事务错误 - 对
TEMPORARY TABLE的操作不受主事务影响，但这是例外，不是通用解法
想中止操作？别写 ROLLBACK，改用 SIGNAL
很多人想在触发器里做业务校验（比如金额不能为负），然后手动 ROLLBACK，结果报 ERROR 1305 (42000): FUNCTION does not exist——这不是函数缺失，是 MySQL 拦截了非法事务语句。
正确做法是抛异常让主语句失败，由 MySQL 自动回滚整个事务：
IF NEW.amount < 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount cannot be negative'; END IF;
注意：
- 必须用
SIGNAL，且只能在BEFORE触发器中生效（AFTER中触发时主语句已执行，无法阻止） -
MESSAGE_TEXT最长 128 字符，超长会被截断，不报错但信息丢失 - 不要试图在
SIGNAL后写清理逻辑，它之后的语句不会执行
真正容易被忽略的隐式提交点
除了显眼的 COMMIT，这些操作一样危险：
-
ALTER TABLE、DROP VIEW、CREATE INDEX：DDL 全部隐式提交 - 任何对 MyISAM 表的操作（哪怕只是
SELECT）：引擎不支持事务，强制提交 -
LOCK TABLES：不仅加锁，还会隐式提交当前事务 - 跨库写入时没带库名，如
INSERT INTO audit_log→ 实际去当前默认库找表，找不到就静默失败，但若误命中同名 MyISAM 表，就触发隐式提交
最隐蔽的是：你以为只读查询很安全，但在触发器里执行 SELECT ... FOR UPDATE 或未走索引的 UPDATE，可能升级为表锁并间接导致事务提前提交——这时 SHOW ENGINE INNODB STATUS 才是你该看的日志，不是错误堆栈。
