MySQL批量加字段需用“ADD COLUMN 字段1 类型, ADD COLUMN 字段2 类型”语法，支持5.7+原子性，但带DEFAULT的NOT NULL字段在8.0.12前会触发全表重建，8.0.12+启用INSTANT仅限末尾、允许NULL或带DEFAULT的列。
直接加字段不报错，但线上表一动就卡顿甚至锁表——ALTER TABLE ADD COLUMN 看似简单，实际执行时是否阻塞读写、旧数据怎么填、字段放哪、约束怎么设，全取决于你写的那条语句里有没有关键参数。
不加位置参数时，默认追加到表末尾
省略 FIRST 和 AFTER 时，MySQL 把新列加在所有现有列之后。这最安全，也最兼容老版本（5.7+ 全支持），但表结构可读性可能变差——比如把 updated_at 放在 created_at 前面，逻辑就乱了。
- 执行语句：
ALTER TABLE users ADD COLUMN status TINYINT NOT NULL DEFAULT 1; - 旧数据该字段会自动填入
DEFAULT值（这里是1），不会为NULL - 如果没写
DEFAULT且字段是NOT NULL，语句会直接报错：ERROR 1138: Invalid use of NULL value - 大表（千万行以上）执行时，MySQL 通常要重建整张表，期间
SELECT可能被阻塞（取决于存储引擎和 MySQL 版本；InnoDB 在 5.6+ 支持部分ALGORITHM=INPLACE，但ADD COLUMN仍常触发拷贝）
用 AFTER 或 FIRST 指定字段位置，小心隐式锁和兼容性
AFTER existing_column 和 FIRST 能让字段顺序符合业务逻辑，但它们不是“轻量操作”：MySQL 必须重排列定义，某些场景下会强制降级为 COPY 算法，耗时更长、锁更久。
- 想把
phone加在email后面：ALTER TABLE users ADD COLUMN phone VARCHAR(20) AFTER email; -
FIRST很少用，除非真需要主键或标识字段打头；但注意：如果表已有主键，ADD id INT PRIMARY KEY FIRST会失败，因为一张表只能有一个主键 - MySQL 8.0.19+ 才支持
AFTER用于ADD COLUMN；低于此版本（如 5.7）用AFTER会报错：ERROR 1064: You have an error in your SQL syntax - 部分 DBA 团队明令禁止用
AFTER/FIRST，理由是迁移、备份、跨版本同步时行为不稳定
添加 VARCHAR 类型字段必须指定长度
VARCHAR 不像 INT 或 CHAR 可以省略参数——漏写括号里的数字，语句立刻失败。
- 错误写法：
ALTER TABLE logs ADD COLUMN remark VARCHAR;→ 报错：ERROR 1064: You have an error in your SQL syntax - 正确写法：
ALTER TABLE logs ADD COLUMN remark VARCHAR(255);或更精确地按业务定长，如VARCHAR(50) - 同理，
DECIMAL必须写DECIMAL(M,D)，ENUM必须列全枚举值：ENUM('active','inactive') - 别图省事用超大长度（如
VARCHAR(1000)），它会影响内存临时表和排序缓冲区使用，间接拖慢查询
一次性加多个字段，能减小锁表时间但不能跳过校验
用一条 ALTER TABLE 加多个列，比发多条语句略快（减少网络往返和元数据锁竞争），但每列仍独立校验、逐个填充默认值，总耗时基本不变。
- 语法：
ALTER TABLE users ADD COLUMN avatar_url VARCHAR(255), ADD COLUMN last_login DATETIME DEFAULT NULL; - 所有新增列共享同一事务上下文，要么全成功，要么全失败
- 如果其中某一列定义非法（比如第二个列用了未支持的
AFTER），整条语句回滚，前面已定义的列也不会生效 - 别指望靠“批量加字段”绕过大表风险——锁表时间仍由最耗时的那个字段决定（通常是带
DEFAULT的大文本列）
真正容易被忽略的是：即使加了 DEFAULT，MySQL 在 5.7 及以前版本对已有数据仍会物理更新每一行（填默认值），导致 I/O 爆增；8.0.12+ 引入“即时 DDL”，才真正实现元数据层面添加带默认值的列——但前提是字段不能是 JSON、TEXT、BLOB，也不能用 AFTER/FIRST。所以别只看语法，得盯紧你的 MySQL 版本和字段类型组合。
