SQL触发器会在表的插入、更新或删除操作前后自动执行，它和激发它的那条DML语句处于同一个事务中。一旦触发器内部逻辑复杂，事务提交就会被推迟，导致表上持有的锁长时间不释放，其他会话访问同一张表时就会发生阻塞。
触发器引起表锁时间过长的原因
理解下面几个机制，就能明白为什么触发器容易拖慢整个系统。
触发器与父事务共用一个事务
无论是BEFORE还是AFTER触发器，都运行在引发它的语句所属的事务里。只有该事务提交或回滚，锁才会释放。
常见拖慢触发器的操作
- 在触发器里对大表做全表扫描或聚合统计
- 触发器内再对别的表做写操作，形成锁链
- 调用存储过程或函数，内部包含网络调用或睡眠
- 在触发器中进行游标循环逐行处理
如何减少触发器内的事务时长
原则一：让触发器只做必要的小事
触发器内只保留校验和极简的字段赋值，不要写复杂业务逻辑。
原则二：把耗时动作改为异步
可以借助消息表，触发器只插入一条待处理记录，后台任务再异步消费。
-- 创建消息表，用于解耦耗时逻辑 CREATE TABLE order_sync_queue ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 轻量触发器，只写队列 CREATE TRIGGER trg_after_order_insert AFTER INSERT ON orders FOR EACH ROW BEGIN INSERT INTO order_sync_queue(order_id) VALUES (NEW.id); END;
原则三：避免触发器中的长事务写法
下面这种在触发器里循环更新其他表的写法会显著拉长事务，应尽量避免。
-- 不推荐：触发器内循环更新，锁时长随行数增长
CREATE TRIGGER trg_bad_example
AFTER INSERT ON users
FOR EACH ROW
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE uid BIGINT;
DECLARE cur CURSOR FOR SELECT id FROM user_logs WHERE user_id = NEW.id;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur;
read_loop: LOOP
FETCH cur INTO uid;
IF done THEN LEAVE read_loop; END IF;
UPDATE user_logs SET status = 1 WHERE id = uid;
END LOOP;
CLOSE cur;
END;
通过监控确认锁等待
在MySQL中可以用下面语句观察当前锁等待，验证触发器优化效果。
-- 查看当前被阻塞和持有锁的事务 SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, b.trx_id blocking_trx_id FROM information_schema.innodb_lock_waits w JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;
总结建议
触发器本身不是性能问题的根源，问题在于把重逻辑放进了一个无法提前结束的事务中。设计时应遵循轻量、同步只做记录、耗时逻辑异步化的思路，必要时用消息表或外部任务队列承接业务动作。这样既能保留触发器的便利性，也能有效控制表锁定时间，提升数据库整体并发表现。