隐式事务本身不直接导致锁等待，但会让触发器的锁行为失控——它把本该短平快的单语句操作拖进不可见、不可控、不及时提交的事务壳子；一旦SET autocommit=0或START TRANSACTION，触发器内DML（如INSERT INTO audit_log）将延迟至手动COMMIT才释放锁，若含SELECT FOR UPDATE或无索引UPDATE，则持续持有行锁/间隙锁，应用层忘提交时锁挂起数十秒，后续访问同范围的查询全被阻塞。
隐式事务本身不直接导致锁等待，但会让触发器的锁行为失控——它把本该短平快的单语句操作，拖进一个不可见、不可控、不及时提交的事务壳子里。
隐式事务如何让触发器锁住整张表
MySQL 默认 autocommit=1，单条 INSERT/UPDATE 是独立事务；一旦你执行 SET autocommit = 0 或显式 START TRANSACTION，后续所有语句（包括触发器内执行的 DML）都会被裹进同一个事务里。问题在于：
- 触发器里的
INSERT INTO audit_log不再是“秒级提交”，而是要等到你手动COMMIT才释放锁 - 如果触发器内还有
SELECT ... FOR UPDATE或没走索引的UPDATE config SET value = ? WHERE module = 'x'，就会在事务中持续持有行锁或间隙锁 - 应用层忘记
COMMIT或卡在 HTTP 调用上，锁就挂起几十秒，后面所有想碰同一行或同一索引范围的查询全被堵死
为什么 SHOW ENGINE INNODB STATUS 看不到阻塞源头
因为隐式事务下的触发器锁等待，往往藏在“看不见的事务”里：
-
INNODB_TRX表里能看到TRX_STATE = LOCK WAIT，但TRX_QUERY显示的是主 SQL（如UPDATE orders SET status = 2 WHERE id = 1001），不是触发器那句UPDATE stats SET count = count + 1 WHERE type = 'order' - 真正持锁的事务可能
TRX_STARTED很早、TRX_QUERY为空（已执行完但没提交），只能靠TRX_MYSQL_THREAD_ID去查PROCESSLIST对应连接是否处于 Sleep 状态 - 死锁日志里出现跨表等待（如事务 A 持
orders锁等stats，事务 B 反过来），却找不到触发器语句痕迹——因为它被吞进父事务上下文，不单独成行
哪些隐式事务场景最危险
以下情况一开隐式事务，触发器立刻变成锁放大器：
- ORM 框架（如 Django 的
transaction.atomic()、Spring 的@Transactional）包裹了带触发器的写操作，但业务逻辑中途抛异常未回滚，事务悬停 - 存储过程中调用
INSERT触发触发器，而该过程本身在autocommit = 0下运行，且末尾漏掉COMMIT - MySQL 客户端工具（如 MySQL Workbench）开启“Safe Updates”后自动加事务，你执行一条
UPDATE，触发器往日志表插数据，结果忘了COMMIT - 触发器内调用另一个含 DML 的存储过程，而该过程默认不 commit —— 锁层层嵌套，释放时机完全不可预测
最易被忽略的一点：触发器从不声明自己的事务边界。它只认当前会话的 autocommit 状态和最近一次 START TRANSACTION。只要外面套了一层没关的事务，它就自动沦为长事务的共犯。
