为什么MySQL中DROP TABLE也会被长事务阻塞-mysql教程-PHP中文网

drop table卡在waiting for table metadata lock是因为需获取mdl_exclusive锁，而未提交事务持有mdl_shared读锁与其互斥；即使事务无实际sql（如仅begin未commit），也会持续持锁阻塞ddl。

为什么mysql中drop table也会被长事务阻塞

为什么 DROP TABLE 会卡在 Waiting for table metadata lock

DROP TABLE 被阻塞，不是它自己慢，而是它拿不到 MDL_WRITE 锁——这个锁被一个未提交的长事务死死攥着。只要那个事务还开着（哪怕只执行了 BEGIN 没任何 SQL），它就持续持有 MDL_READ 锁，而 DROP TABLE 必须等这个锁释放才能继续。

常见现象包括：

SHOW PROCESSLIST 里看到 DROP TABLE 状态是 Waiting for table metadata lock
同时还有若干 SELECT、UPDATE 也卡在这个状态，形成雪崩式堆积
查 INFORMATION_SCHEMA.INNODB_TRX 发现某个 TRX_STARTED 时间远早于当前，但 TRX_QUERY 为空——说明它只是开了事务没干活，但锁一直没放

长事务怎么就拦住了 DROP TABLE

关键点在于：MySQL 的元数据锁（MDL）机制不区分“读”和“写”的语义强度，只看锁类型是否兼容。DROP TABLE 需要 MDL_EXCLUSIVE（等价于 MDL_WRITE），而任何活跃事务（哪怕只是空事务）在打开表时都会加 MDL_SHARED（MDL_READ）。这两者互斥。

也就是说，以下任意一种情况都足以拦停 DROP TABLE：

应用层 ORM（如 Django 的 atomic 块）开启事务后异常退出，没 COMMIT 或 ROLLBACK
连接池配置不当，AUTOCOMMIT=0 的连接复用后残留未结束事务
监控脚本执行了无 LIMIT 的全表 SELECT，且没设查询超时

为什么 SHOW PROCESSLIST 看不到真正拦路的事务

SHOW PROCESSLIST 显示的是“正在等待”的线程，不是“正在持锁”的线程。真正挡路的那个长事务可能状态是 Sleep 或 Query 已结束，但它所属的事务仍处于 RUNNING 状态——只有查 INFORMATION_SCHEMA.INNODB_TRX 才能暴露它。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

推荐诊断 SQL：

SELECT TRX_ID, TRX_MYSQL_THREAD_ID, TRX_STATE, 
       TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) AS trx_duration_sec,
       TRX_QUERY 
FROM INFORMATION_SCHEMA.INNODB_TRX 
WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 10;

注意：TRX_QUERY 为空 ≠ 安全；trx_duration_sec > 10 就该介入，别等它到 60 秒才动手。