先确认是否锁冲突而非语法错误：若alter table等ddl卡住、超时或报error 1205/1099，或phpmyadmin转圈断连，大概率是mdl或行锁被占；执行select * from performance_schema.metadata_locks、innodb_trx、innodb_lock_waits定位持锁与阻塞源。
怎么看是不是锁冲突，而不是语法错误
执行 ALTER TABLE、DROP INDEX 等 DDL 报错时，先别急着改 SQL。MySQL 的锁冲突通常不报“Lock”字眼，而是表现为长时间卡住、超时，或直接返回 ERROR 1205 (40001): Deadlock found when trying to get lock 或 ERROR 1099 (HY000): Table 'xxx' was locked by another thread。但更常见的是无报错假死：phpMyAdmin 页面转圈几十秒后提示“连接已断开”或“查询超时”。这时大概率是元数据锁（MDL）或行锁被占——不是语句写错了，而是别人正拿着锁。
查谁在持有或等待 MDL 锁
phpMyAdmin 的「SQL」页能直接运行诊断语句。重点查三张表：
-
performance_schema.metadata_locks：看哪些表被GRANTED（已持有）或PENDING（正在等） -
information_schema.INNODB_TRX：找TRX_STATE = 'RUNNING'且TRX_STARTED时间异常早的事务（比如几小时前） -
information_schema.INNODB_LOCK_WAITS：直接关联出blocking_trx_id和waiting_trx_id，明确谁堵了谁
例如，执行以下联查可一眼定位阻塞链：
SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread,
b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread
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;
注意：若结果为空，但 DDL 仍卡住，说明可能是长事务未提交（没触发锁等待，但 MDL 被隐式占用），此时重点盯 INNODB_TRX 中 TRX_STARTED 最老的几条记录。
为什么 KILL 了线程，DDL 还是卡着不动
常见误区是看到 SHOW PROCESSLIST 里有个 ALTER TABLE 线程状态为 Waiting for table metadata lock，就去 KILL 它——它很可能是受害者，而非加锁者。真正的问题往往在上游：
- 一个未提交的
UPDATE或SELECT ... FOR UPDATE事务，正持有行锁或意向锁，导致后续 DDL 拿不到 MDL_EXCLUSIVE - 另一个
ALTER TABLE正在执行中（哪怕只改了个小字段），MySQL 8.0 前会全程持锁，新 DDL 只能排队等 - 应用层连接池维持了空闲连接，里面有个事务
START TRANSACTION后什么都没做，却一直没COMMIT或ROLLBACK
所以 KILL 前务必用 SELECT * FROM information_schema.PROCESSLIST WHERE ID = ? 查清目标线程的 COMMAND 和 STATE：如果是 Sleep 且 TIME > 300，大概率是悬挂事务；如果是 Query 且 INFO 显示 ALTER TABLE，则优先查它的 blocking 来源，而不是杀它。
DDL 失败后残留的锁怎么清理
DDL 执行中断（比如你手动点了停止、浏览器关了、或超时断开），MySQL 不一定自动回滚——尤其是涉及 ALGORITHM=COPY 的操作，可能已建好临时表但没完成切换，留下孤儿对象和未释放的 MDL。
- 检查是否有临时表：
SHOW TABLES LIKE '#sql%';，存在则需DROP TABLE `#sql_xxx`;（注意反引号） - 确认是否还有未清理的触发器或外键残留：用
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'your_table';核对约束数量是否与预期一致 - 如果表结构看起来正常但反复锁住，执行
OPTIMIZE TABLE your_table;可强制重建并释放潜在碎片锁（适用于 InnoDB 表）
最易被忽略的一点：phpMyAdmin 的「刷新」按钮不会重置连接状态，旧事务可能还挂在后台。真正释放锁，靠的是断开连接或显式 COMMIT/ROLLBACK ——而 phpMyAdmin 默认不开启自动提交，这点必须心里有数。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
