mysql 5.7 支持真·在线（lock=none）的 alter 操作包括：add column（5.7.5+，无not null约束时）、增大varchar长度、add index、drop index、rename index、rename column（5.7.6+）；而modify column缩小长度、drop column、change column、删除主键等需重建表，不支持lock=none。
能在线改，但不是所有操作都真正无锁；必须结合 ALGORITHM=INPLACE 和 LOCK=NONE 显式指定，并用实际执行结果验证是否生效。
哪些 ALTER 操作支持真·在线（LOCK=NONE）？
MySQL 5.7 的 Online DDL 支持程度高度依赖具体操作类型，不能只看文档列表——有些操作在理论上支持，但实际执行时仍会因引擎限制或参数组合失败。
-
ADD COLUMN：5.7.5+ 支持ALGORITHM=INPLACE, LOCK=NONE，但若字段加NOT NULL且无默认值，会强制降级为COPY（报错ERROR 1846 (HY000): ALGORITHM=INPLACE is not supported...） -
MODIFY COLUMN：增大VARCHAR长度从 50 到 100 可以在线，但缩小长度或改类型（如INT→BIGINT）大概率触发重建，5.7.23+ 才稳定支持部分增大场景 -
DROP COLUMN、CHANGE COLUMN、RENAME COLUMN：前两者基本需重建表；RENAME COLUMN（5.7.6+）是元数据变更，可LOCK=NONE -
ADD INDEX/DROP INDEX：全部支持INPLACE，且允许并发 DML；但FULLTEXT索引首次创建仍可能退化
为什么加了 ALGORITHM=INPLACE, LOCK=NONE 还被锁表？
两个常见原因：一是 MySQL 自动降级算法，二是外部阻塞源未清理。
- 即使显式写了
ALGORITHM=INPLACE，MySQL 仍可能根据列定义、存储格式、主键变更等内部判断，悄悄回退到COPY并加LOCK=SHARED—— 此时你看到的其实是“伪在线” - 长事务未结束会持有
MDL锁，导致 DDL 卡在等待状态：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'your_table';（需提前开启performance_schema） - 活跃事务中存在未提交的
UPDATE/DELETE，也会让INPLACE-REBUILD类操作在应用临时日志阶段卡住
怎么确认一次 ALTER 真正在线执行了？
别信返回的 “Query OK”，要看执行过程中的并发表现和系统视图反馈。
- 执行前先清长事务：
SELECT * FROM information_schema.innodb_trx WHERE TIME > 60;，手动KILL掉超时事务 - 执行时开另一个会话持续写入：
INSERT INTO your_table (...) VALUES (...);，观察是否被阻塞（超时或锁等待） - 查进度：
SELECT * FROM information_schema.innodb_alter_table;—— 若有记录且state是copy to tmp table，说明已退化为 COPY；若只有元数据变更且无该行，则大概率是真 INPLACE - 监控临时日志：
SHOW STATUS LIKE 'Innodb_online_alter_log_max_size';和Innodb_online_alter_log_used，溢出会导致失败回滚
大表改结构时，pt-online-schema-change 还值得用吗？
它不是备选方案，而是兜底手段——当原生 Online DDL 明确不支持你的操作（比如收缩 VARCHAR、改主键）时才考虑，但要清楚代价。
- 触发器真实存在开销：每条业务
INSERT/UPDATE/DELETE都多一次影子表同步写入，QPS > 5k 时 CPU 和 I/O 上升明显 - binlog 增大一倍以上，主从延迟风险高；如果业务依赖强一致性（如金融类），建议停写窗口内走原生 DDL
- 它无法绕过
MDL锁竞争，若线上有频繁短事务，仍可能卡在Waiting for table metadata lock
真正容易被忽略的是：临时日志大小 innodb_online_alter_log_max_size 默认仅 128MB，而一个 50GB 表在添加索引期间产生的 DML 日志很容易突破这个值，直接导致 DDL 中断并回滚——调大前务必评估变更窗口内的写入量。
