为什么MySQL在执行Alter Table过程中会出现Waiting for table metadata lock？-mysql教程-PHP中文网

Waiting for table metadata lock 是 ALTER TABLE 在等待 MDL_EXCLUSIVE 锁，因其他连接持有 SHARED_READ 或 SHARED_WRITE 锁未释放；常见于未提交事务、长事务或异常退出连接；需通过 performance_schema.metadata_locks 和 INNODB_TRX 联合定位持锁线程，优先 KILL QUERY 再考虑 KILL。

为什么mysql在执行alter table过程中会出现waiting for table metadata lock？

Waiting for table metadata lock 不是表被锁死了，而是你的 ALTER TABLE 操作卡在等一个排他元数据锁（MDL），而这个锁正被别的连接悄悄攥着不放。

为什么ALTER TABLE必须等MDL_EXCLUSIVE？

MySQL 对表结构的修改（比如加字段、改类型）必须确保期间没人读/写这张表的元信息——否则会破坏一致性。所以 ALTER TABLE 会尝试获取 MDL_EXCLUSIVE 锁，但它和任何已存在的 MDL_SHARED_READ 或 MDL_SHARED_WRITE 锁互斥。

常见触发场景：

某个连接执行过 SELECT * FROM t，但 autocommit=0 且没 COMMIT 或 ROLLBACK，它就一直持着 SHARED_READ
一个长事务正在跑 UPDATE 或 INSERT，哪怕只涉及几行，也会持有该表的 SHARED_WRITE
应用异常退出后连接没关闭，但事务状态仍为 RUNNING，锁还在

为什么SHOW PROCESSLIST找不到真正持锁者？

SHOW PROCESSLIST 只显示线程当前动作状态，不反映锁持有关系。一个 Command = 'Sleep'、Time = 1200、Info = NULL 的连接，很可能就是罪魁祸首——它早已执行完语句，但事务没结束，MDL 锁没释放。

必须查 performance_schema.metadata_locks：

SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, PROCESSLIST_ID
FROM performance_schema.metadata_locks m
JOIN performance_schema.threads t ON m.OWNER_THREAD_ID = t.THREAD_ID
WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table'
  AND LOCK_STATUS = 'GRANTED';

重点看 LOCK_STATUS = 'GRANTED' 的行，对应 PROCESSLIST_ID 就是真正在 hold 锁的线程 ID。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

如何确认那个“Sleep却RUNNING”的悬挂事务？

单靠 INNODB_TRX 可能漏掉已断连但未清理的事务；单靠 PROCESSLIST 又容易把空闲连接当嫌疑对象。要联合查：

SELECT t.trx_id, t.trx_started, t.trx_state, p.ID, p.USER, p.HOST, p.COMMAND, p.TIME, p.INFO
FROM information_schema.INNODB_TRX t
JOIN information_schema.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID
WHERE p.COMMAND = 'Sleep' AND t.trx_state = 'RUNNING'
ORDER BY t.trx_started;

如果 trx_started 是 20 分钟前，COMMAND 是 Sleep，INFO 为空，基本可以确定：它开了事务，啥也没干，就卡在这儿占着 MDL。

KILL之前先试KILL QUERY，别一上来就杀连接

直接 KILL [thread_id] 会强制回滚整个事务，如果它已写了大量数据，回滚可能持续几分钟甚至更久，期间依然阻塞其他操作。

更稳妥的做法：

先 KILL QUERY [thread_id]：只中断当前语句，事务还活着，但锁通常会释放（尤其对纯 SELECT 场景）
观察 ALTER TABLE 是否开始执行；如果没反应，再 KILL [thread_id]
注意：Python 的 pymysql 或 aiomysql 默认 autocommit=False，脚本里只查不提交 + 不 close()，就是典型隐患源

真正的难点不在怎么 kill，而在怎么快速从一堆 Sleep 连接里揪出那个“安静但致命”的事务——它不报错、不打日志、不占 CPU，只默默卡住所有 DDL 和后续查询。