触发器不直接持mdl锁，但执行时会为所访问的所有表（主表+触发器内涉及表）统一申请mdl读锁，且需全部获取成功才执行；若任一表被ddl持有写锁，则整个dml阻塞于“waiting for table metadata lock”。
触发器本身不直接持有MDL锁，但它的执行会隐式参与表的元数据锁生命周期——只要触发器里访问了其他表，就会为那些表额外申请MDL读锁；而如果触发器嵌套、或与DDL并发，就极易卡在Waiting for table metadata lock状态。
触发器执行时MDL锁是怎么被拿的
MySQL对每个DML语句（比如INSERT、UPDATE）执行前，会为涉及的**所有表**（包括主表 + 触发器中SELECT/INSERT/UPDATE访问的表）统一加MDL读锁。这个动作是原子的：要么全部拿到，要么全部阻塞等待。
- 主表（比如
orders）已有长事务未提交 → 后续所有对该表的MDL读锁请求都会排队 - 触发器里又去查
users表 → 那么这条DML实际需要orders和users两张表的MDL读锁 - 如果此时有人正对
users执行ALTER TABLE→users的MDL写锁没释放 → 整条DML就被卡住，状态变成Waiting for table metadata lock
为什么触发器比普通SQL更容易引发锁等待
根本原因是触发器把“隐式依赖”变成了“强MDL耦合”，而且开发者通常意识不到它在锁层面的开销。
- 触发器逻辑藏在数据库层，应用侧看不到它访问了哪些表，排查时容易漏掉
information_schema.TRIGGERS里的定义 - 一个
UPDATE orders可能通过触发器连带访问logs、notifications、audit_trail三张表 → 实际锁表数×4，冲突概率指数上升 - 触发器里用了子查询或
JOIN，且被JOIN的表没走索引 → 可能触发全表扫描 → 升级为表锁 → 进一步拖长MDL持有时间 - MySQL 8.0+ 中，触发器执行期间若遇到死锁重试，会反复尝试获取MDL锁，加剧排队
快速定位触发器是否是元数据锁源头
别只盯着SHOW PROCESSLIST里状态为Waiting for table metadata lock的线程，得顺藤摸瓜找出它背后真正卡在哪张表、谁在占着不放。
- 先查当前所有等待MDL的线程：
SELECT THREAD_ID, EVENT_NAME, SOURCE, OBJECT_SCHEMA, OBJECT_NAME FROM performance_schema.events_waits_current WHERE EVENT_NAME = 'wait/lock/metadata/sql/mdl' AND STATE = 'WAITING';
- 再关联
performance_schema.threads拿到SQL文本，确认是否含触发器调用痕迹（如TRIGGER字样或明显非业务SQL） - 查触发器定义：
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db';
，重点看ACTION_STATEMENT里有没有跨表操作 - 最后用
SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0）或INNODB_TRX+INNODB_LOCK_WAITS（5.7）反查阻塞源，确认是不是某个DDL正在改触发器里引用的表
避免触发器引发MDL问题的实操建议
不是不能用触发器，而是得控制它的“锁辐射半径”。线上高并发场景下，尤其要警惕多表联动型触发器。
- 触发器里只操作单表，且该表就是主表本身（比如自增字段更新、状态自动置位）→ 最安全，MDL锁范围可控
- 必须跨表？改用异步方式：触发器里只写一条轻量消息到
queue_log表，由后台Job消费并执行后续逻辑 → 把同步MDL依赖拆成异步解耦 - 禁用触发器中
SELECT ... FOR UPDATE或UPDATE其他业务表 → 这类操作不仅加MDL读锁，还会加InnoDB行锁，双重阻塞风险 - DDL变更前，先检查
information_schema.TRIGGERS，确认没有触发器依赖目标表 → 尤其是准备ALTER TABLE users前，扫一遍有没有触发器在读users
最隐蔽的坑在于：你查SHOW PROCESSLIST看到一堆线程卡在Waiting for table metadata lock，但KILL掉几个后新连接立刻又排上队——这时候大概率是触发器把多张表绑在了一起，而其中一张正被DDL钉死。不翻触发器定义、不查data_lock_waits，光杀进程只是扬汤止沸。
