mysql元数据锁（mdl）阻塞需通过information_schema.innodb_trx和sys.schema_table_lock_waits定位，筛选长事务、确认阻塞者sql及线程id后，用kill pid释放锁，ddl前应设lock_wait_timeout防挂起。
查 information_schema.INNODB_TRX 看谁卡着元数据锁
MySQL 的元数据锁（MDL）不走 InnoDB 事务日志，没法从 SHOW PROCESSLIST 直接看出谁在阻塞 DDL。真正能定位源头的是 information_schema.INNODB_TRX 配合 performance_schema.metadata_locks（5.7+）或 sys.schema_table_lock_waits（8.0+）。
实操建议：
• 先跑 SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60，筛出运行超 1 分钟的事务
• 再连查 performance_schema.threads 拿到对应线程的 PROCESSLIST_ID 和 SQL
• 注意：TRX_STATE = 'RUNNING' 不代表没锁，它可能刚执行完 UPDATE 正卡在 COMMIT 前——这种事务照样持有 MDL
用 sys.schema_table_lock_waits 快速定位 DDL 阻塞链
8.0 默认启用 sys 库，schema_table_lock_waits 是现成的“阻塞关系图谱”，比手拼表快得多。
常见错误现象：
• 执行 ALTER TABLE t ADD COLUMN x INT 卡住，但 SHOW PROCESSLIST 显示状态是 Waiting for table metadata lock
• 查 sys.schema_table_lock_waits 发现 BLOCKING_TRX_ID 对应一个老事务，而它的 SQL_TEXT 是 SELECT ... FOR UPDATE 或未提交的 UPDATE
实操建议：
• 运行 SELECT * FROM sys.schema_table_lock_waits\G，重点关注 BLOCKING_TRX_ID、BLOCKING_PID、BLOCKING_SQL
• 如果 BLOCKING_SQL 为空，说明阻塞者是隐式事务（比如 autocommit=0 下只执行了 INSERT 没 COMMIT）
• BLOCKING_PID 就是能直接 KILL 的线程 ID
KILL 前先确认事务上下文，别误杀长查询
DDL 被阻塞时，阻塞者未必是 bug 或异常，可能是业务里合法的长事务（比如报表导出、批量更新）。盲目 KILL 会导致数据不一致或应用报错。
使用场景：
• 阻塞者 TRX_QUERY 是 SELECT ... FOR UPDATE，且已运行 10 分钟以上 → 大概率可杀
• 阻塞者 TRX_QUERY 是 UPDATE t SET ... WHERE ...，但 TRX_ROWS_MODIFIED = 0 → 事务卡在应用层没提交，可沟通后杀
参数差异：
• KILL QUERY <code>pid 只中断当前语句，不回滚事务 → 对 MDL 无效（锁还在）
• 必须用 KILL <code>pid 强制终止整个连接，才能释放 MDL
• 杀之前建议先 SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = <code>pid 确认 PROCESSLIST_INFO 内容
预防：DDL 操作前加 LOCK WAIT TIMEOUT 控制等待上限
线上执行 DDL 时，没人想干等 5 分钟突然失败。MySQL 5.7.21+ 支持在 DDL 语句里显式设锁等待超时，避免无限挂起。
性能 / 兼容性影响：
• SET lock_wait_timeout = 10 是会话级，不影响其他连接
• 但 ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 这类语句仍可能因底层条件不满足而退化为拷表，此时锁等待逻辑不同，lock_wait_timeout 不生效
实操建议：
• 执行前先 SET lock_wait_timeout = 30
• 再跑 ALTER TABLE t ADD COLUMN x INT
• 如果报错 ERROR 1205 (40001): Deadlock found when trying to get lock; try restarting transaction 或 ERROR 3027 (HY000): Lock wait timeout exceeded，说明有冲突，立刻收手排查
• 别依赖 innodb_lock_wait_timeout，那是针对 InnoDB 行锁的，对 MDL 无效
MDL 阻塞最难搞的不是找不到谁在占着，而是那个“占着的人”其实在等另一个应用层逻辑——比如一个 HTTP 请求开了事务，中间调第三方 API 超时了，自己忘了 rollback。这种得翻应用日志，数据库里只看到个空 TRX_QUERY。
