根本原因是ALTER TABLE需获取MDL_EXCLUSIVE锁，而该锁与任何未释放的MDL_SHARED_READ锁（如未提交的SELECT）互斥；只要存在长事务、Sleep连接或ORM隐式事务未提交，DDL就会卡在“Waiting for table metadata lock”，阻塞所有读写。
ALTER TABLE 在 MySQL 中导致业务锁表，根本原因不是“操作慢”，而是它在多数场景下必须获取排他性元数据锁（MDL_EXCLUSIVE），而这个锁会直接阻塞所有对目标表的读写——包括 SELECT、INSERT、UPDATE、DELETE。
这和行锁、InnoDB 事务隔离级别无关，是 MySQL Server 层的元数据保护机制。只要锁没拿到，后续所有语句都会卡在 Waiting for table metadata lock 状态，业务就“不动了”。
为什么 ALTER TABLE 总是卡在 Waiting for table metadata lock
这不是表数据被占着，是“抢锁失败”：
MySQL DDL 操作（如 ALTER TABLE）需要 MDL_EXCLUSIVE 锁，但只要有一个活跃连接还在用这张表，哪怕只是执行过一句 SELECT * FROM t 并没提交，它就一直持有 MDL_SHARED_READ 锁；两者互斥，DDL 只能等。
-
SHOW PROCESSLIST里看到大量Command = Sleep、Time > 300、Info = NULL的线程，大概率就是持锁者 -
information_schema.INNODB_TRX里trx_state = 'RUNNING'且TIME_TO_SEC(NOW() - trx_started) > 60的事务要优先 kill -
SHOW OPEN TABLES WHERE In_use > 0对 MDL 无效，别依赖它 -
lock_wait_timeout控制 MDL 等待超时，默认是 31536000 秒（一年），所以你看到的是“挂住”，不是报错
ALGORITHM=INPLACE 和 LOCK=NONE 为什么经常失效
它们不是开关，而是声明式约束，MySQL 会严格校验是否真能走 inplace：
一旦不满足条件，5.7 就直接报错退出，不会静默退化；8.0.12+ 虽支持部分操作无锁，但限制极多。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 加
NOT NULL DEFAULT字段 → 表非空时必须全表回填，默认退化为COPY -
MODIFY COLUMN VARCHAR(255) → VARCHAR(1024)→ 若触发长度头升级（1字节→2字节），5.7/8.0 均强制重建 - 添加唯一索引 → 存在重复值、含
BLOB字段、有外键时，仍 fallback 到重建 - 务必先用
EXPLAIN FORMAT=JSON查执行计划，确认"alter_algorithm": "inplace"和"lock": "none"同时出现
真正绕开锁表的方案只有 pt-online-schema-change
它不走 MySQL 原生 DDL 流程，而是用影子表 + 触发器 + 分块同步来模拟变更：
整个过程原表读写基本不受影响，但前提是：表必须有主键或唯一非空索引；不能已有触发器；不能在从库单独运行（pt-osc 不复制 DDL，会导致主从结构不一致）。
- 执行前加
--dry-run --print看它生成的 SQL，重点核对RENAME TABLE顺序和库名 - 分块大小（
--chunk-size）要调低，避免单次拷贝压垮 IO 或触发 long query kill - 切换瞬间（
RENAME）仍需短暂加 MDL，但耗时在毫秒级，高并发下也可能抖动
真正容易被忽略的是：MDL 锁的持有者未必是“正在跑 SQL”的连接，而很可能是那个忘了 COMMIT 的 Sleep 连接，或者应用端连接池里长期空闲却未释放的连接。查锁不能只盯 INNODB_TRX，得联合 PROCESSLIST 和业务上下文一起看。
