删除字段需重写整张表，而mysql 5.6后add column支持元数据修改实现秒级添加；drop column则必须逐行重组记录，且受索引、外键、触发器等约束影响，常退化为锁表copy模式，推荐用pt-online-schema-change或手动建新表切换。
删除字段要重写整张表，增加字段通常不用
MySQL 5.6 之后对 ADD COLUMN 做了优化：如果加的是非 NULL 默认值字段（比如 ADD COLUMN status TINYINT DEFAULT 0），InnoDB 可以只修改表元数据、不触碰现有数据页，瞬间完成。但 DROP COLUMN 没这个捷径——它必须逐行读取、重组每条记录，把旧字段的字节从行结构里剥掉，再写回磁盘。哪怕字段是空的，也要走一遍全表 I/O。
索引和外键让删除字段雪上加霜
如果被删字段参与了任何索引（包括主键、唯一索引、普通索引），或被其他表的外键引用，DROP COLUMN 就会触发连锁反应：
- 所有含该字段的索引必须重建，不只是删除索引本身
- 外键约束检查会扫描子表，确认无依赖；若存在，直接报错
ERROR 1553 (HY000): Cannot drop index 'xxx': needed in a foreign key constraint - 即使没外键，InnoDB 仍要校验字段是否被触发器、生成列、虚拟列间接引用
在线 DDL 模式下锁表现差异极大
ADD COLUMN 在 ALGORITHM=INPLACE 模式下基本只锁 MDL（元数据锁），DML 可并发；而 DROP COLUMN 即使指定 ALGORITHM=INPLACE，在多数 MySQL 版本中仍会退化为 COPY 模式——意味着全程锁表、阻塞写入。你看到的“卡住”，其实是表被独占锁定，连 SELECT ... FOR UPDATE 都会被挂起。
真正能绕开慢删除的实操路径只有两条
别指望 ALTER TABLE ... DROP COLUMN 在千万级以上表上快起来。可靠方案就两个：
- 用
pt-online-schema-change工具，它通过影子表 + 触发器同步实现“无锁”删除，但要求业务能容忍几秒延迟和额外磁盘空间 - 手动建新表：用
CREATE TABLE new_table AS SELECT col1,col2,... FROM old_table拷贝需要的字段，再原子切换RENAME TABLE—— 这种方式可控，但需提前停写或用应用层双写兜底
注意：TRUNCATE 或 OPTIMIZE TABLE 对删除字段无效，它们不改变列定义；想省事直接删表重建？那得确认所有依赖对象（视图、存储过程、应用代码）都已适配，否则上线即故障。
