MySQL元数据锁（MDL）超时由lock_wait_timeout控制，而非innodb_lock_wait_timeout；该参数分SESSION和GLOBAL两级动态设置，但仅加速报错，无法根治阻塞，根本解决需排查并终止长事务或DDL阻塞源。
MySQL元数据锁超时不是由innodb_lock_wait_timeout控制的
很多人一看到“锁超时”就去改innodb_lock_wait_timeout，但这个参数只管行锁（InnoDB记录锁、间隙锁等），对Waiting for table metadata lock完全无效。真正控制元数据锁（MDL）等待超时的是lock_wait_timeout，它独立于InnoDB引擎，属于server层参数。
如何临时调整lock_wait_timeout
该参数支持会话级和全局级动态设置，无需重启XAMPP：
- 仅影响当前连接：执行
SET SESSION lock_wait_timeout = 10;（单位秒） - 影响后续所有新连接（需SUPER权限）：执行
SET GLOBAL lock_wait_timeout = 10; - 注意：
SET GLOBAL对已存在的连接不生效，包括你当前正在用的phpMyAdmin或Navicat连接 - XAMPP默认root无SUPER权限？可先用命令行登录：
mysql -u root -p（空密码或按你设的），再执行SET GLOBAL
为什么改了lock_wait_timeout还是卡在Waiting for table metadata lock
调低这个值只能让报错更快（比如从卡5分钟变成10秒就报Lock wait timeout exceeded），但解决不了根本问题。常见原因包括：
- 有长事务未提交，且该事务访问过你要ALTER的表（哪怕只是
SELECT） - 另一个连接正在执行
ALTER TABLE、DROP TABLE等DDL，而你试图同时SELECT或UPDATE同一张表 - 客户端断连但事务没自动回滚（尤其PHP脚本异常退出、连接池未正确close）
-
lock_wait_timeout设得太小（如1秒），反而让正常短DDL被误杀，引发更多重试和争抢
XAMPP环境下排查和清理MDL阻塞的实操步骤
打开XAMPP控制面板 → 点击Shell按钮 → 进入MySQL命令行：
- 查谁在等锁：
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_STATE = 'Waiting for table metadata lock'; - 查谁拿着锁不放：
SELECT * FROM information_schema.processlist WHERE COMMAND != 'Sleep' AND TIME > 60; - 确认阻塞源头后，用
KILL <code>thread_id;干掉它（比如KILL 123;） - 更稳妥的方式是先看事务：
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5;，重点看trx_state和trx_started - XAMPP的MySQL默认没有启用
performance_schema？可在my.cnf的[mysqld]段下加performance_schema = ON并重启
真正难处理的不是超时时间，而是那些看不见的、没提交的事务——它们可能藏在某个PHP页面里，执行完UPDATE却忘了commit，或者被Apache子进程继承后长期滞留。这种场景下，光调参数毫无意义。
