mysql 5.6+ alter table 并非全部在线，是否锁表取决于操作类型与版本：5.6起支持algorithm=inplace但范围有限，8.0扩展后仍存在拷表或mdl等待场景，如修改text默认值、change column、加全文索引等。
mysql 5.6+ alter table 为什么还会锁表
不是所有 ALTER TABLE 都能在线执行，是否锁表取决于操作类型和 MySQL 版本。5.6 开始支持 ALGORITHM=INPLACE，但仅对部分变更生效；8.0 扩展了支持范围，但像修改 TEXT 列默认值、重命名列（CHANGE COLUMN）、加全文索引等仍会触发拷表或元数据锁等待。
-
ADD COLUMN在末尾且不带DEFAULT（或DEFAULT NULL）通常可在线；加非空DEFAULT值会触发全表初始化，即使用了ALGORITHM=INPLACE -
MODIFY COLUMN改类型（如VARCHAR(100) → VARCHAR(200)）一般安全；但改成更严格类型（如加NOT NULL）需校验全表数据，容易卡住 - 用
pt-online-schema-change或gh-ost是绕过锁的主流方案，但它们本身有复制延迟、binlog 增量应用开销，不是“无代价”的替代
如何快速确认当前 ALTER 是否正在锁表
别只盯着 SHOW PROCESSLIST 里状态为 altering table 的线程——它可能早已拿到元数据锁（MDL），正阻塞其他查询。真正要查的是谁在等锁、谁持有锁。
- 查等待关系：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING';
- 查持有者：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'GRANTED';
- 结合
information_schema.INNODB_TRX看长事务：SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;
—— 一个未提交的UPDATE就能让后续ALTER卡死
online DDL 耗时突然飙升的三个常见原因
即使 ALGORITHM=INPLACE 成功启用，耗时也可能远超预期，问题往往不在 DDL 本身，而在配套环境。
- 磁盘 I/O 瓶颈：
ALTER过程中大量读写临时排序文件、二级索引重建，SSD 性能下降 30% 就会让 10 分钟操作拖到 1 小时+ - buffer pool 溢出：大表 DDL 会频繁访问页，若
innodb_buffer_pool_size不足，引发大量物理读，SHOW ENGINE INNODB STATUS中可见file reads/s异常高 - 从库延迟放大：主库
ALTER完成后，从库需重放整个 DDL（即使 online），若从库负载高或网络抖动，延迟可能突增数小时；8.0.23+ 可开启slave_parallel_type = LOGICAL_CLOCK+slave_preserve_commit_order = ON缓解
为什么 pt-online-schema-change 有时比原生命令还慢
pt-online-schema-change 的原理是建影子表、同步增量、原子切换，看似无锁，但实际耗时受业务写入强度影响极大。
- 当表每秒写入超 500 QPS，
pt-osc的DELETE/INSERT增量同步会和业务争抢 CPU 和 I/O，导致整体时间翻倍甚至失败 - 没加
--chunk-index或索引选择不当，会导致 chunk 扫描慢、锁行时间长，SHOW PROCESSLIST里能看到大量Copying rows状态 - 误用
--no-check-alter跳过语法检查，结果在拷贝中途报错（比如字段长度超限），回滚成本比原生ALTER更高
真正关键的不是“用不用工具”，而是理解你这张表的写入模式、索引分布、主从拓扑——这些决定了锁在哪、卡多久、能不能切。
