ALTER TABLE卡住本质是MDL写锁被未释放的读锁阻塞，需定位并终止持锁事务而非等待DDL完成；必须显式指定ALGORITHM=INPLACE, LOCK=NONE，结合performance_schema.metadata_locks精准排查持锁源头。
ALTER TABLE 上线时卡住，不是因为“锁表没释放”，而是你没绕开元数据锁（MDL）的持有者。真正要解决的，是让 DDL 不被阻塞，而不是等它自己跑完。
确认 MySQL 版本和引擎是否支持 Online DDL
MySQL 5.6+ 的 InnoDB 支持部分 ALTER TABLE 操作在线执行，但不是所有操作都无锁：
- ADD COLUMN、DROP COLUMN、ADD INDEX 在多数场景下可走 ALGORITHM=INPLACE
- MODIFY COLUMN 类型变更、CHANGE COLUMN、RENAME COLUMN 可能仍需拷表（ALGORITHM=COPY）
- MyISAM 引擎不支持 Online DDL，任何 ALTER TABLE 都会全程表锁
- 必须确认表用的是 InnoDB： SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';
上线前强制指定 ALGORITHM 和 LOCK 策略
别依赖默认行为。MySQL 默认可能选错算法，尤其在低版本或参数未调优时。
显式加约束才能控住锁级别：
- 优先用：ALTER TABLE t ADD COLUMN c INT, ALGORITHM=INPLACE, LOCK=NONE;
- 若报错 “LOCK=NONE is not supported”，说明该操作无法完全无锁，降级为：LOCK=SHARED（允许读，阻塞写）或 LOCK=DEFAULT
- ALGORITHM=COPY 一定触发全表拷贝 + 排他锁，线上严禁直接用
- 查看实际执行计划：加 EXPLAIN FORMAT=TRADITIONAL ALTER TABLE ...（MySQL 8.0.23+）或观察 performance_schema.events_statements_current 中的 ALGORITHM 字段
避开 MDL 持锁事务，而不是杀等待线程
DDL 卡在 Waiting for table metadata lock，SHOW PROCESSLIST 里看到的“等待线程”只是受害者，真凶是某个 Command='Sleep' 却长期持有 MDL 的连接。
必须查 performance_schema.metadata_locks：
- 确保已启用：SELECT * FROM performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';，若 ENABLED='NO'，先执行：UPDATE performance_schema.setup_instruments SET ENABLED='YES' WHERE NAME='wait/lock/metadata/sql/mdl';
- 定位持锁者：SELECT PROCESSLIST_ID, PROCESSLIST_USER, PROCESSLIST_HOST, LOCK_TYPE, LOCK_STATUS FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA='your_db' AND OBJECT_NAME='your_table' AND LOCK_STATUS='GRANTED';
- 对应 PROCESSLIST_ID 执行：KILL QUERY [id]（先尝试中断当前语句），再 KILL [id]（如仍不释放）
- 最常见持锁者：BEGIN 了没 COMMIT 的事务，information_schema.INNODB_TRX 中 trx_state='RUNNING' 且 trx_started 时间远超业务预期
上线窗口期必须做三件事
DDL 上线不是执行一条 SQL 就完事：
- 提前在从库或影子库上验证 ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 是否真能成功，注意磁盘空间是否足够（InnoDB 临时排序区、undo log 增长）
- 设置超时：在客户端层加 max_execution_time=30000（单位毫秒），避免 DDL 卡死影响连接池
- 监控配合：上线后立即查 SELECT * FROM performance_schema.data_locks WHERE OBJECT_SCHEMA='your_db' AND OBJECT_NAME='your_table';，确认没残留行锁或意向锁
- 别忘了 binlog 格式：若用 ROW 格式，ALGORITHM=INPLACE 的 DDL 仍会记录完整表变更，CDC 工具可能误判——MySQL 9.6.0 起才把外键/级联逻辑上移到 SQL 层统一记录，老版本得靠业务层兜底
真正麻烦的从来不是 DDL 本身，而是它暴露了那些“以为提交了其实没提交”的悬挂事务，以及没被注意到的 LOCK=DEFAULT 回退。上线前不查 metadata_locks，等于蒙眼开车。
