DDL卡住连接池时，SHOW PROCESSLIST中State列大量显示“Waiting for table metadata lock”，且Command='Sleep'但Time值极高，表明MDL锁阻塞；需查information_schema.PROCESSLIST筛选ALTER TABLE语句，并结合performance_schema.metadata_locks定位持有SHARED_READ_ONLY锁的长事务。
怎么看是不是DDL卡住了连接池
直接查 SHOW PROCESSLIST，重点看 State 列是否大量出现 Waiting for table metadata lock。如果同时有几十个连接卡在这个状态，基本可以锁定是 MDL 锁阻塞——而最常见诱因就是未完成的 ALTER TABLE。
再补一句：别只盯着 Command = 'Query' 的连接。那些 Command = 'Sleep' 但 Time 值高达几百秒的连接，往往是因为被前面的 MDL 锁堵住后，应用层重试或超时前一直挂着，它们不是“空闲”，是“卡死”。
怎么快速定位正在执行的DDL语句
运行这条 SQL：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND INFO LIKE '%ALTER TABLE%' ORDER BY TIME DESC LIMIT 5;
它能筛出当前正在跑的 ALTER 语句，包括完整 SQL 和已执行时间。注意两点：
-
INFO字段可能被截断，用SHOW FULL PROCESSLIST或查performance_schema.events_statements_current（MySQL 5.7+）获取完整语句 - 如果没查到活跃 ALTER，但仍有大量
Waiting for table metadata lock，说明 DDL 已排队等待锁，还没真正开始执行——此时要查谁占着表的读锁（比如长事务中的 SELECT）
为什么加字段也会让连接池爆满
不是所有 ALTER TABLE ... ADD COLUMN 都安全。关键看 MySQL 版本和字段位置：
- MySQL 8.0.12+，末尾加列且无默认值 → 默认走
ALGORITHM=INSTANT，毫秒级，不锁表 - 加在中间、带
DEFAULT、或 MySQL INPLACE 或COPY，需要全表元数据排他锁 - 一旦需要排他锁，所有新来的 SELECT/INSERT 都得排队等这个锁，连接池瞬间积压
所以别信“只是加个字段很轻”——先用 EXPLAIN FORMAT=JSON ALTER TABLE t ADD COLUMN x INT（MySQL 8.0.19+）或查官方文档确认算法，否则就是埋雷。
临时止血和后续动作怎么做
如果已经爆满，优先保业务：
- 用
KILL干掉那个卡住的ALTER进程（KILL），而不是干掉一堆 Sleep 连接——后者只是症状，前者才是病根id - 检查并
KILL长事务（SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED），释放它持有的表级读锁 - 之后必须走在线 DDL 工具：对大表，一律用
gh-ost或pt-online-schema-change，它们通过影子表+触发器绕过 MDL 锁
最容易被忽略的一点：DDL 变更窗口期必须预留“锁等待超时”余量。比如你设了 lock_wait_timeout=60，但业务接口超时是 3 秒，那这 60 秒里所有新请求都会失败——不是锁的问题，是应用没做好熔断降级。
