触发器本身不直接锁表，而是继承调用SQL的锁行为；其锁类型取决于原始语句是否命中索引、隔离级别及条件类型，常见锁表现实为全表扫描或间隙锁所致。
触发器本身不直接锁表，但会继承调用它的 SQL 的锁行为
MySQL 触发器（BEFORE 或 AFTER）没有独立的锁机制，它运行在触发它的语句事务上下文中。也就是说：如果触发器是被一条 UPDATE users SET status=1 WHERE id=100 激活的，那它执行时持有的锁，完全取决于这条 UPDATE 语句实际加了什么锁——可能是行锁，也可能是表锁，关键看是否命中索引、隔离级别、WHERE 条件类型。
常见误解是“触发器导致锁表”，其实真正锁表的是外面那条没走索引的 UPDATE 或 DELETE。触发器只是被动执行者，但它可能让锁持有时间变长（比如触发器里又去查/更新其他表），间接放大锁冲突。
- 若原始语句走全表扫描（如
WHERE name LIKE '%abc%'且name无索引），InnoDB 会锁住所有扫描到的行，接近表锁效果 -
BEFORE INSERT触发器中执行SELECT ... FOR UPDATE，会额外申请新锁，可能和外部事务形成交叉等待 - 触发器里调用存储过程或 UDF，若内部有显式
LOCK TABLES（极少见但合法），才会真正锁表
REPEATABLE READ 下的间隙锁（Gap Lock）常被误认为“锁整张表”
在默认隔离级别 REPEATABLE READ 中，InnoDB 对范围条件（如 BETWEEN、>=、LIKE 'a%'）不仅加记录锁，还会加间隙锁。例如：
UPDATE orders SET paid = 1 WHERE created_at > '2026-04-01';
如果 created_at 没有索引，这条语句会扫描全表，并对所有“间隙”加锁（包括最大值之后的间隙）。这时另一个事务想插入 created_at = '2026-04-15' 的新订单，就会被阻塞——看起来像“表被锁死”，其实是间隙锁在起作用。
触发器若被这类语句激活，会继承这些间隙锁，且触发器逻辑若再操作相同索引区间，极易引发死锁（ERROR 1213）。
- 间隙锁只在 RR 隔离级别生效；切换到
READ COMMITTED可禁用间隙锁（但需评估幻读风险） -
SELECT ... LOCK IN SHARE MODE或FOR UPDATE在触发器中出现时，同样受间隙锁影响 - 用
EXPLAIN确认原始语句是否走了索引，比盯着触发器代码更有效
触发器中显式事务控制（START TRANSACTION）会导致严重锁升级
触发器内**严禁**使用 START TRANSACTION、COMMIT 或 ROLLBACK。MySQL 会直接报错：ERROR 1305 (42000): SAVEPOINT does not exist 或更隐蔽的锁异常。原因在于：触发器必须运行在父事务原子性约束下，不能开启子事务。
但有些开发者会绕过限制，在触发器里调用含事务的存储过程，或依赖 ORM 自动开启事务——这会导致锁范围意外扩大，甚至让行锁退化为表锁（尤其在 MyISAM 表上，不过现在极少用）。
- 触发器中所有 DML 操作都共享父事务的锁，无法提前释放
- 若触发器执行慢（如循环插入日志表 + 调用 HTTP 接口），父事务锁持有时间拉长，死锁概率陡增
- MyISAM 存储引擎不支持行锁，任何写操作都是表级锁——若触发器操作 MyISAM 表，必然锁表
排查时别只看触发器，先确认原始语句的锁类型
当遇到“触发器导致锁表”，第一反应不该是重写触发器，而是查清楚触发它的那条语句到底干了什么。最有效的三步：
1. 用 SHOW PROCESSLIST 找出状态为 Updating 或 Locked 的线程，记下 Id
2. 查这个线程正在执行的 SQL：SELECT INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = [线程id]
3. 对该 SQL 执行 EXPLAIN，重点看 type（是否 ALL？）、key（是否用了索引）、rows（扫描行数）
如果 EXPLAIN 显示 type: ALL 且 rows 接近表总行数，基本可以确定：不是触发器的问题，是业务 SQL 写错了索引或条件。
真正需要动触发器逻辑的情况极少，通常是它里面做了不该做的事：比如在 AFTER UPDATE 里又去 UPDATE 同一张表（可能触发递归或锁升级），或者调用了一个未优化的存储过程。
