能加，但加法不当易锁表、卡业务或失败；mysql的add column受版本、引擎、字段位置和约束影响极大，线上应慎用默认追加、指定位置、not null+default等高危写法，并优先采用pt-online-schema-change等工具灰度变更。
能加，但加法不对容易锁表、卡业务、甚至失败。 MySQL 的 ALTER TABLE ... ADD COLUMN 看似简单，实际执行时受版本、存储引擎、字段位置和约束影响极大，不是所有写法都安全。
ADD COLUMN 默认加在表尾，但线上表慎用
不指定位置时，新字段默认追加到最后一列：ALTER TABLE users ADD email VARCHAR(100);。这在 MySQL 5.6+ InnoDB 中是「在线 DDL」（instant 或 inplace），通常不锁表。但注意：
- 如果表有全文索引（FULLTEXT）、空间索引（SPATIAL）或使用 MyISAM 引擎，该操作会全程锁表
- MySQL 5.5 或更早版本对任何
ADD COLUMN都需要拷贝全表，耗时且阻塞写入 - 即使支持 online DDL，大表（千万级以上）仍可能因元数据锁（MDL）短暂阻塞后续查询
指定位置（AFTER / FIRST）会强制重建表
用 AFTER existing_column 或 FIRST 改变字段顺序，InnoDB 必须重建整张表（copy algorithm）：
-
ALTER TABLE users ADD phone VARCHAR(20) AFTER email;→ 触发全表拷贝，时间与数据量正相关 -
FIRST同样触发重建，且可能打乱原有字段物理顺序，影响部分 ORM 映射逻辑 - MySQL 8.0.12+ 对
AFTER有优化，但仅限于新增字段类型与原表兼容、无排序依赖的场景，不可依赖
带 NOT NULL + DEFAULT 的字段，版本行为差异极大
这是最容易踩坑的点。写法：ALTER TABLE users ADD status TINYINT NOT NULL DEFAULT 1;
- MySQL 5.6/5.7：若表非空，该语句会为所有已有行填充默认值 → 触发全表更新，IO 和锁开销高
- MySQL 8.0.13+：引入「instant ADD COLUMN」，只要字段允许 NULL 或带 DEFAULT，就跳过行更新，仅改元数据 → 几乎瞬时完成
- 但注意：如果 DEFAULT 值是函数（如
CURRENT_TIMESTAMP），哪怕在 8.0 也会退化为 copy 模式
批量 ADD 多个字段，不等于省事
一条语句加多个字段看似高效：ALTER TABLE users ADD col1 INT, ADD col2 VARCHAR(50), ADD col3 DATETIME;
- 所有字段仍按声明顺序依次添加，底层仍是单次 DDL 操作，不会分拆
- 只要其中任一字段触发 copy 模式（比如用了
FIRST或某字段 DEFAULT 是函数），整条语句就退化为全表重建 - 错误回滚代价高：若中途失败（如磁盘满），已添加的字段不会自动回退，需人工清理
真正关键的不是“能不能加”，而是“加的时候表还在不在服务”。生产环境加字段前，务必查清 MySQL 版本、引擎、表大小，并在低峰期用 pt-online-schema-change 或 gh-ost 做灰度变更——直接跑 ALTER TABLE 的风险，常被日志里一闪而过的 Waiting for table metadata lock 掩盖。
