pt-online-schema-change能避开元数据锁，因其新建空影子表、用触发器捕获增量变更、分块拷贝历史数据，全程不触发mysql原生ddl的全表重建与mdl等待。
ALTER TABLE在5.7中默认走重建表流程
MySQL 5.7 对绝大多数 ALTER TABLE 操作（如修改字段类型、加索引、改字符集）不支持真正的就地修改，而是强制执行「重建表」：创建临时表 → 全量拷贝数据 → 重建索引 → 原子重命名。这个过程全程持有 MDL 写锁和表级写锁，任何 SELECT、INSERT、UPDATE、DELETE 都会被阻塞，直到切换完成。
哪怕只是把 varchar(255) 改成 varchar(1024)，只要触发存储格式变更（比如长度头从1字节升为2字节），5.7 就会退化为重建；NOT NULL DEFAULT 字段新增也需回填默认值，同样无法跳过物理扫描。
常见错误现象：SHOW PROCESSLIST 中大量线程卡在 Waiting for table metadata lock，业务读写完全停滞。
长事务是MDL锁阻塞的隐形推手
MySQL 5.7 的 MDL 锁是事务级的：只要一个会话开启了事务（哪怕只执行了 SELECT * FROM t），且未提交或回滚，它就会持续持有该表的 MDL 读锁；而 ALTER TABLE 必须获取 MDL 写锁，二者互斥。
- 典型场景：DBA 执行
ALTER TABLE user ADD COLUMN last_login DATETIME，但应用端有个长达2小时未提交的SELECT ... FOR UPDATE事务，DDL 就会一直等待 -
innodb_lock_wait_timeout默认 50 秒，只控制行锁等待；而MDL锁等待超时由lock_wait_timeout控制（默认 31536000 秒，即一年），所以常“卡住不动”而非报错 - 查证方式：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60找出长事务
ALGORITHM=INPLACE 并不等于“不锁表”
5.7 支持 ALGORITHM=INPLACE，但它不是万能开关——是否真走 inplace，取决于操作类型和表定义：
- 添加普通字段（
ADD COLUMN）通常可 inplace，但若含NOT NULL DEFAULT且表非空，仍需全表回填，默认退化为COPY - 添加唯一索引（
ADD UNIQUE INDEX）虽标称 inplace，但在某些条件下（如存在重复值校验、大 BLOB 字段）仍可能降级 - 必须用
EXPLAIN FORMAT=JSON查看实际执行计划，确认"alter_algorithm": "inplace"和"supports_inplace": true -
LOCK=NONE在 5.7 中仅对部分操作有效（如加普通索引），且要求无长事务、无外键、无全文索引等限制
为什么pt-online-schema-change是更可靠的选择
它绕开了 MySQL 原生 DDL 的锁机制，用影子表 + 触发器 + 增量同步模拟在线变更：
- 建新表（
user_new）并执行结构变更 - 用
INSERT/UPDATE/DELETE触发器捕获原表所有变更，实时同步到新表 - 最后通过原子
RENAME切换表名，切换窗口通常在毫秒级 - 全程不阻塞原表 DML，但要注意触发器开销、binlog 增长、磁盘空间占用（约等于原表两倍）
真正容易被忽略的是：即使用了 pt-osc，如果原表上有未提交的长事务，它在创建触发器阶段仍需获取 MDL 写锁——这个短暂窗口依然可能被阻塞。所以，清理长事务永远是第一步。
