alter table ... algorithm=inplace仍会卡住，因其在准备和提交阶段需获取排他元数据锁（x mdl），若遇长事务持有s mdl则阻塞，进而导致后续所有dml因无法获取s锁而挂起。
MySQL在线DDL操作本身不等于“零锁”，ALTER TABLE加ALGORITHM=INPLACE仍会在元数据锁（MDL）层面产生短暂但关键的X锁，一旦被长事务阻塞，就会引发连锁等待。真正要解决的不是“怎么让DDL不加锁”，而是“怎么不让它被卡住”。
为什么ALTER TABLE ... ALGORITHM=INPLACE还会卡住？
很多人误以为只要加了ALGORITHM=INPLACE就全程无锁，其实它只保证数据行变更阶段避免全表拷贝，但两个环节仍需强一致的排他元数据锁（X MDL）：
- 初始准备阶段：校验表结构、分配内部资源，必须获取X锁
- 最终提交阶段：原子性更新数据字典（如
mysql.table），必须获取X锁
只要此时有任意一个活跃事务（哪怕只是SELECT * FROM t没提交）持有了该表的S MDL，X锁请求就会排队，后续所有新DML也因无法获取S锁而集体挂起——这就是“一个DDL拖垮整张表”的根源。
快速定位持锁长事务的三步法
别先看SHOW FULL PROCESSLIST里谁在Waiting for table metadata lock，那是结果；要直接揪出源头。用以下组合查：
- 查长时间未结束的事务：
SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY duration_sec DESC LIMIT 5，重点关注duration_sec > 60且trx_state = 'RUNNING'的 - 查Sleep状态的老连接：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 300，TIME > 300（5分钟）是高危信号 - 交叉验证：
SELECT * FROM information_schema.innodb_lock_waits可确认等待关系，但注意它只显示当前活跃等待，不保留历史
KILL前必须确认的两件事
盲目KILL可能引发应用层事务异常或主从延迟跳变。执行前务必确认：
- 该线程是否属于业务核心服务（查
HOST和USER，比对服务注册中心或部署清单） - 其
trx_query是否为空或为简单SELECT——如果是UPDATE或INSERT且已执行部分逻辑，KILL会回滚全部变更，需评估业务影响
更稳妥的做法是先尝试KILL QUERY <thread_id></thread_id>（只中断当前语句，不杀连接），观察是否释放MDL；若无效再KILL <thread_id></thread_id>。
如何避免下次再被卡住？
技术上能做的其实很朴素：让DDL避开长事务窗口。线上高频表的DDL必须配合业务低峰+主动清理：
- 执行DDL前，用脚本自动检测目标表是否存在活跃事务：
SELECT COUNT(*) FROM information_schema.innodb_trx t JOIN information_schema.innodb_locks l ON t.trx_id = l.lock_trx_id JOIN information_schema.innodb_lock_waits w ON l.lock_trx_id = w.blocking_trx_id WHERE l.lock_table LIKE '%`your_db`.`your_table`%' - 所有ORM/框架连接池强制配置
autocommit=true，尤其警惕Python的aiomysql、Java的spring-jdbc默认开启事务却不自动提交的陷阱 - 监控项必须包含：
information_schema.PROCESSLIST中Sleep连接TIME > 300的数量告警，以及Waiting for table metadata lock状态连接数突增
最常被忽略的一点：MySQL 8.0.12+支持ALTER TABLE ... ALGORITHM=INSTANT，仅修改列名、注释等元数据时真正零锁，但它不适用于加索引、改类型等操作——别把INSTANT当成万能解药，得看具体DDL类型。
