MySQL 5.7中真正支持LOCK=NONE的ALTER操作仅限：ADD COLUMN（5.7.5+且无NOT NULL无默认值）、ADD/DROP INDEX、RENAME COLUMN（5.7.6+）、MODIFY COLUMN增大VARCHAR长度；其余如DROP COLUMN、CHANGE COLUMN、删主键等均强制重建表，LOCK=NONE被静默忽略。
哪些ALTER操作在MySQL 5.7中能真正LOCK=NONE？
不是所有标称“支持Online DDL”的操作都真能无锁。MySQL 5.7.32实际可做到LOCK=NONE的，只有这几类：ADD COLUMN（5.7.5+，且不能带NOT NULL无默认值）、ADD INDEX/DROP INDEX、RENAME COLUMN（5.7.6+）、ALTER TABLE ... MODIFY COLUMN仅限**增大VARCHAR长度**（如VARCHAR(50)→VARCHAR(100)）。其他如DROP COLUMN、CHANGE COLUMN、修改字段类型（INT→BIGINT）、删主键等，一律触发表重建，LOCK=NONE会被MySQL静默忽略。
为什么指定了ALGORITHM=INPLACE, LOCK=NONE还是卡住？
两个最常被忽略的降级原因：
一是长事务未清理——任何未提交的事务都会持有MDL锁，DDL会卡在Waiting for table metadata lock；
二是列定义隐式触发重建——比如给ADD COLUMN加了NOT NULL但没设DEFAULT，MySQL直接报错ERROR 1846 (HY000): ALGORITHM=INPLACE is not supported并回退到COPY模式。
执行前务必检查：
SELECT * FROM information_schema.innodb_trx WHERE TIME > 60;-
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'your_table';（需提前开启performance_schema）
怎么验证一次ALTER是不是真在线？
别信Query OK返回。关键看三件事：
• 执行期间另开一个会话持续写入：INSERT INTO your_table (...) VALUES (...);，如果超时或报Lock wait timeout exceeded，说明已锁表；
• 查information_schema.innodb_alter_table：如果有记录且state是copy to tmp table，就是退化成COPY；
• 监控临时日志膨胀：SHOW STATUS LIKE 'Innodb_online_alter_log_max_size';，若日志撑满（默认128MB），会导致DDL失败回滚，大表尤其危险。
大表DDL必须绕开的三个坑
生产环境最容易栽在这三点：
• innodb_online_alter_log_max_size太小：默认128MB，亿级表变更期间DML密集时极易溢出，建议按预估变更时间×QPS×平均行大小上浮50%设置；
• 主从延迟爆炸：即使主库真在线，从库SQL线程单线程重放DDL日志，可能延迟数小时，读写分离架构下业务查到过期数据；
• 磁盘空间误判：INPLACE-REBUILD类操作（如加索引）仍会生成临时文件，需要额外1.2倍原表空间，不是“完全不占空间”。
