应 kill blocking_pid对应持锁连接而非waiting_pid；用sys.schema_table_lock_waits定位阻塞链，结合innodb_trx查trx_state='running'且trx_started异常早的悬挂事务。
DDL卡住不是DDL慢，是它被别的事务按住了——绝大多数情况，根源不在ALTER语句本身，而在某个没提交的SELECT或DML正拿着S MDL锁不放。
查谁在等、谁在堵：直接看sys.schema_table_lock_waits
这是MySQL 5.7+自带的诊断视图，一行就暴露等待链：
- 执行
SELECT * FROM sys.schema_table_lock_waits;，结果里BLOCKING_TRX_ID对应的就是持有S锁的源头事务ID -
WAITING_TRX_ID是被卡住的DDL（比如ALTER TABLE），WAITING_PID是它的线程ID -
OBJECT_SCHEMA和OBJECT_NAME能立刻定位到哪张表被锁死 - 如果没开
sys库或权限受限，退而用SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'PENDING';找等待项，再关联OBJECT_SCHEMA/OBJECT_NAME反查表
定位持有S MDL锁的长事务：重点盯information_schema.INNODB_TRX
SHOW PROCESSLIST里的Sleep状态不可信——它可能正拿着MDL锁喝咖啡。必须查真实事务状态：
- 运行
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' ORDER BY trx_started LIMIT 5;，关键看trx_started时间是否异常早（比如几小时甚至几天前） - 把查到的
trx_mysql_thread_id填进：SELECT THREAD_ID, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_INFO FROM performance_schema.threads t JOIN performance_schema.events_statements_current e USING (THREAD_ID) WHERE t.PROCESSLIST_ID = ?;，确认它到底在执行什么 - 常见陷阱：Python/Java连接池没显式
close()，或DBA在客户端执行BEGIN后忘了COMMIT，事务就一直挂着S锁
ALGORITHM=INPLACE, LOCK=NONE为什么还是阻塞
这个组合不等于“绝对不锁”，生效条件非常苛刻：
-
LOCK=NONE只对“仅改元数据”类操作真正有效，比如MySQL 8.0.12+的ADD COLUMN（INSTANT）、DROP INDEX -
MODIFY COLUMN或CHANGE COLUMN（如INT → BIGINT）在MySQL 5.7中仍需REBUILD，即使ALGORITHM=INPLACE，也会在应用增量阶段短暂加XMDL锁 - 用
INFORMATION_SCHEMA.INNODB_METRICS查dml_rows_inserted等指标突降，能佐证是否真有DML被卡住，而非应用层超时假象
从库上DDL导致SQL线程停摆：别指望并行复制救场
从库SQL线程单线程串行重放DDL，根本不是延迟，是复制链路“断流”：
-
slave_parallel_type=database对DDL完全无效：DDL自带全库级MDL锁升级，所有worker都会被路由到同一个线程 -
slave_parallel_type=logical_clock也仅缓解：DDL不产生writeset，前后事务的时间戳切片对它无效 - 实操更可靠的做法是“绕过复制”：
STOP SLAVE SQL_THREAD;→ 在从库手动执行DDL（前提：已用pt-table-checksum校验主从一致性）→START SLAVE
真正容易被忽略的是：MDL锁的持有者可能根本不在当前会话列表里——它可能来自一个已断开但未清理的连接，或一个隐式开启却从未提交的事务。排查时别只盯着SHOW PROCESSLIST的Time列，得交叉验证performance_schema.metadata_locks和INNODB_TRX才能准确定位。
