触发器本身不自动加表级锁，它复用当前sql已持有的锁；myisam下看似“自动锁表”实为其引擎表锁机制所致，innodb中则按行锁规则执行。
触发器执行时会自动加表级锁吗
不会。MySQL 的触发器本身不主动申请任何锁，它运行在当前 SQL 语句已持有的锁上下文中。也就是说，INSERT 触发器执行时，如果原语句已经对表加了 AUTO_INC 锁或行锁（InnoDB）或表锁（MyISAM），触发器里的操作会复用这些锁；但触发器内部的 SELECT、UPDATE 等语句仍按常规隔离级别和存储引擎规则加锁——不会额外升级为表级锁。
想在触发器里强制加表级锁该怎么做
不能直接在触发器中执行 LOCK TABLES 或 FLUSH TABLES WITH READ LOCK，MySQL 会报错：ERROR 1312 (0A000): PROCEDURE xxx can't return a result set in the given context 或更常见的 ERROR 1315 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration，根本原因是触发器属于“非自主事务上下文”，禁止显式锁表、提交/回滚、调用存储过程（含锁操作）等。
- 替代方案是把需要锁表的逻辑提到应用层：先
LOCK TABLES t1 WRITE，再执行触发器依赖的主语句，最后UNLOCK TABLES - 若必须在数据库侧控制，改用存储过程封装整个流程，而非依赖触发器
- InnoDB 下更推荐用
SELECT ... FOR UPDATE或UPDATE ... WHERE配合唯一索引实现行级排他，避免粗粒度锁表
触发器 + MyISAM 表为什么看起来像“自动锁表”
因为 MyISAM 默认使用表级锁，任何写操作（INSERT/UPDATE/DELETE）都会对整张表加写锁，而触发器语句作为同一语句的延伸，自然被包裹在这个锁周期内。这不是触发器导致的，而是 MyISAM 引擎行为——哪怕没触发器，单条 INSERT 也会锁全表。
- MyISAM 下触发器中的
INSERT INTO log_table会触发log_table的表锁，可能造成锁竞争，尤其当多个触发器写同一日志表时 - 对比 InnoDB：同一事务中触发器更新另一张 InnoDB 表，只会在对应行/页上加锁，不影响其他行
- 所以“触发器引发锁问题”的表象，往往暴露的是底层引擎选型不当，而非触发器本身有问题
高并发下触发器调用外部表更新的锁风险
最典型的坑是触发器里 UPDATE summary_table SET total = total + NEW.amount WHERE id = NEW.category_id——这句看似简单，但在并发 INSERT 时可能产生死锁或锁等待超时（ERROR 1205 (40001): Deadlock found when trying to get lock）。
- 原因：多个触发器事务同时尝试更新
summary_table同一行，且加锁顺序与主表不一致 - 缓解方式：确保所有更新都通过唯一索引定位（如
WHERE id = ?），避免全表扫描导致锁范围扩大 - 更稳妥做法：把汇总逻辑移到应用层异步处理，或用
INSERT ... ON DUPLICATE KEY UPDATE替代触发器内的SELECT + UPDATE两阶段操作
真正难调试的不是“要不要锁”，而是锁的粒度、持有时间、顺序是否可控——触发器让这些隐含行为更难追踪。
