MySQL出现MetadataLock锁等待，如何定位DDL引发的表锁阻塞问题？

本文共计921个文字，预计阅读时间需要4分钟。

由于MySQL的MDL（Metadata Lock）锁是表级别的、隐式的、自动加的，只有当一个事务还在访问某张表时（例如，执行SELECT语句），后续对该表的任何DDL操作（如ALTER TABLE）都必须等待该事务释放MDL读锁。因此，若要避免这种情况，应确保在执行DDL操作前，没有其他事务正在访问该表。这通常通过设置autocommit=0来关闭自动提交，然后执行查询，不进行COMMIT或ROLLBACK，以保持事务状态，从而持续持有MDL读锁。

常见错误现象包括：

• 执行 ALTER TABLE zone 后一直卡住，SHOW PROCESSLIST 显示状态为 Waiting for table metadata lock
• 此时对 zone 表的所有新查询、更新也全部阻塞，不是慢，是彻底挂起
• information_schema.INNODB_TRX 可能查不到活跃事务，但 SHOW OPEN TABLES WHERE In_use > 0 能暴露“被占着却没事务ID”的表

如何快速定位谁在 hold 住 zone 表的 MDL

别只盯着 INNODB_TRX，它只显示 InnoDB 层事务，而 MDL 是 Server 层锁，必须结合多视角交叉验证：

• 先看谁在用这张表：SHOW OPEN TABLES WHERE Table = 'zone' AND In_use > 0 —— 返回的 Id 字段就是线程 ID
• 再查这个线程在干啥：SELECT * FROM information_schema.PROCESSLIST WHERE ID = 12345（把上一步的 ID 填进去）
• 如果 Command 是 Sleep 且 Time 很大（比如 > 300），基本就是它：一个没关的连接，开着事务但忘了提交
• 补充一招：用 SELECT OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'zone'（需开启 performance_schema 且 metadata_locks 表可用）

aiomysql / pymysql 连接不提交导致的 MDL 风险

Python 异步或同步驱动默认 autocommit=False，这意味着哪怕你只执行了一条 SELECT * FROM zone LIMIT 1，只要没显式 commit() 或连接关闭，MDL 读锁就一直挂着。尤其在脚本或测试中容易忽略这点。

• 问题代码典型模式：conn = pymysql.connect(..., autocommit=False) → cur.execute("SELECT ...") → 脚本退出但 conn 没 close()
• 修复方式不是等它超时，而是从源头控制：autocommit=True（适合只读场景）或确保每个逻辑块都包裹 try/finally: conn.commit() / conn.rollback()
• 使用连接池时，aiomysql.create_pool(..., autocommit=True) 是更安全的默认配置，避免单连接长期游离

DDL 操作前必须检查的三件事

线上执行 ALTER TABLE 不是发个命令就完事，它本质是一次高风险元数据变更，容易引发雪崩：

• 确认无长事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60（找运行超 1 分钟的事务）
• 确认无 Sleep 中的连接在用目标表：SHOW PROCESSLIST + SHOW OPEN TABLES 交叉比对
• 确认业务低峰期，并提前通知依赖服务；如果表很大，考虑用 pt-online-schema-change 或 MySQL 8.0+ 的 ALGORITHM=INSTANT 降低锁持有时间

最常被忽略的是：即使 DDL 自己没卡，它也会让后面所有对该表的语句排队等待——这个“等待链”一旦形成，恢复起来比 kill 进程还麻烦。