MySQL MDL (Metadata Lock) 與存儲引擎無關：長事務持有 MDL 導致 DDL 阻塞實戰分析

現象

例行 DROP TABLE history_log_20141017 耗時 15000+ 秒，SHOW PROCESSLIST 顯示 Waiting for table metadata lock。

根因：MDL 機制與長事務

• MySQL 5.5+ 引入 **MDL (Metadata Lock)**，保護表結構不被並發 DDL 破壞。
• 事務開始 → 訪問表 → **持有該表 MDL (SHARED_READ/WRITE)** → 事務提交/回滾前不釋放。
• 備份工具 mysqldump --single-transaction 開啟長事務，期間所有涉及表持有 MDL。
• 同表 DDL（DROP/ALTER/TRUNCATE）需 **EXCLUSIVE MDL**，被阻塞直至長事務結束。

關鍵區別：MDL 與存儲引擎無關

MyISAM、InnoDB、Memory 等**所有引擎**共用同一套 MDL 子系統。引擎只負責數據/索引存取，MDL 在 Server 層統一管理。

5.0/5.1 vs 5.5+ MDL 差異

驗證實驗

-- Session 1
BEGIN;
SELECT * FROM t_myisam;  -- 持有 t_myisam MDL

-- Session 2
DROP TABLE t_myisam;  -- 阻塞：Waiting for table metadata lock

-- Session 1
COMMIT;  -- Session 2 瞬間執行成功

解決與預防策略

1. 避開備份窗口執行 DDL：調度系統在備份結束後運行結構變更。
2. 縮短備份事務：分庫並行備份、--single-transaction --quick --max_allowed_packet=1G。
3. 在線 DDL (5.6+)：ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 減少鎖表時間（但仍需等待 MDL）。
4. 監控長事務：

   SELECT * FROM information_schema.INNODB_TRX 
   WHERE trx_started < NOW() - INTERVAL 1 MINUTE;

5. 殺死阻塞事務（緊急）：KILL trx_mysql_thread_id。

錯誤日誌識別

# error.log
11966363, hardcore, localhost, oss_log, Query, 11084, 
Waiting for table metadata lock, drop table 2014_10_17_oss_abandonquest