ALTER TABLE卡在MDL锁会导致连接数飙升，因其需X锁而被持S锁的长事务阻塞，后续所有对该表的SELECT/INSERT/UPDATE均按FIFO排队等待同一把锁，每个等待连接持续占用连接池名额。
因为 ALTER TABLE 卡在元数据锁（MDL）上时，后续所有对该表的 SELECT、INSERT、UPDATE 都会排队等同一把锁，每个等待连接都占着池子里的一个名额，不超时、不释放——连接池不是“不够用”，是被锁住的连接堵死了。
为什么Waiting for table metadata lock会让连接数飙升
这不是连接泄漏，也不是配置太小，而是 MySQL 的 MDL 锁机制天然会造成“阻塞传导”：
-
ALTER TABLE需要获取表级 MDL 排他锁（X），但前面有个长事务正在执行SELECT * FROM t WHERE ...，它持有该表的 MDL 共享锁（S），ALTER就得一直等 - 此时新来的
SELECT请求也要申请该表的S锁，但它排在ALTER的X锁后面——MySQL 的 MDL 锁队列是 FIFO 且不支持插队 - 结果就是：1 个
ALTER+ N 个等待的SELECT全卡在同一个锁链上，每个都维持一个连接状态，Threads_connected持续逼近max_connections -
SHOW PROCESSLIST里大量显示Waiting for table metadata lock，但Threads_running可能只有个位数——说明不是真在跑 SQL，是在干等
哪些ALTER操作最容易触发这种阻塞
别被“只是加个字段”骗了。是否触发长锁，取决于 MySQL 版本、字段位置、默认值和算法选择：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- MySQL 8.0.12+，末尾加列且无默认值 → 默认走
ALGORITHM=INSTANT，不锁表，安全 - 加在中间、带
DEFAULT值、或 MySQL 版本 INPLACE 或COPY，需要全表元数据排他锁 -
MODIFY COLUMN、CHANGE COLUMN、DROP COLUMN（8.0.12前）基本都走COPY，锁表时间与数据量正相关 - 没显式指定
ALGORITHM和LOCK，MySQL 就按自己规则选——线上环境永远不要依赖默认行为
怎么快速定位是不是DDL在作祟
别只看 SHOW PROCESSLIST，INFO 字段常被截断，得用更可靠的查法：
- 查当前活跃的 DDL：
SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%ALTER TABLE%' AND STATEMENT_NAME = 'Query'; - 查谁在持锁不让路：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60; - 查锁等待链：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema'); - 如果发现一堆连接卡在
Waiting for table metadata lock，但没看到活跃ALTER，说明它还在锁队列里排队，没轮到执行——这时杀掉长事务比杀ALTER更有效
临时止血时最常踩的坑
很多人第一反应是 KILL 所有 Sleep 连接，这是错的：
-
KILL一堆Sleep连接只是清症状，新请求立刻补上，问题照旧 - 真正该杀的是那个卡住的
ALTER进程（KILL <code>id），或者它前面那个持有读锁的长事务 - 用
SHOW FULL PROCESSLIST看不到完整 SQL？那就去performance_schema.events_statements_history_long查历史语句，别靠猜 - 改完结构后立刻上线新代码？小心字段为空或类型不兼容导致应用报错——DDL 成功不等于业务可用
MDL 锁阻塞不是性能问题，是并发控制的刚性体现。它不会因为调大连接池、开线程池、加机器而缓解，唯一解法是让锁持有时间可控——要么用 INSTANT，要么用 gh-ost，要么把变更窗口卡死在低峰期并配上锁检测脚本。
