在 MySQL 中，如果需要一次性批量新增多个字段，通常要使用“ADD COLUMN 字段1 类型, ADD COLUMN 字段2 类型”这一类语法。MySQL 5.7 及以上版本对这类 DDL 操作提供了更完整的原子性支持，也就是说要么整体执行成功，要么统一回滚，避免只修改一半。不过还有一个很关键的细节需要注意：在 8.0.12 之前，新增带 DEFAULT 的 NOT NULL 字段时，往往会触发整表重建；而在 MySQL 8.0.12 及之后，虽然引入了 INSTANT 能力，但依然存在限制，通常只适用于追加到表末尾、允许 NULL，或者带 DEFAULT 的列。
单看加字段这件事，语法本身并不复杂，也未必会立即报错，但线上业务表一旦执行不当，就可能出现卡顿、等待甚至锁表。ALTER TABLE ADD COLUMN 表面简单，实际是否阻塞读写、历史数据如何回填、新字段放在什么位置、约束条件如何设置，往往都取决于 SQL 语句中有没有写对这些关键参数。
不加位置参数时，默认追加到表末尾
如果省略 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，那么 SQL 会直接报错：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+ 才支持在
ADD COLUMN中更稳定地使用AFTER；低版本环境（如部分 5.7 场景）使用时可能报错：ERROR 1064: You ha ve an error in your SQL syntax - 有些 DBA 团队会明确限制使用
AFTER/FIRST，主要原因是它们在迁移、备份恢复以及跨版本同步时，可能带来不稳定或不一致的执行表现
添加 VARCHAR 类型字段必须指定长度
在 MySQL 里，VARCHAR 与 INT、CHAR 等类型不同，定义时必须显式写出长度参数。若遗漏括号中的数字，新增字段语句会立刻执行失败。
- 错误写法：
ALTER TABLE logs ADD COLUMN remark VARCHAR;→ 报错：ERROR 1064: You ha ve 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 同时新增多个列，通常会比连续执行多条 SQL 略快一些，因为它减少了网络往返和元数据锁竞争。但需要明确的是，每个新增列依然会分别进行合法性校验，也会逐一处理默认值回填，因此总体耗时并不会因为“批量添加字段”而明显缩短。
- 语法：
ALTER TABLE users ADD COLUMN a vatar_url VARCHAR(255), ADD COLUMN last_login DATETIME DEFAULT NULL; - 所有新增列处于同一事务上下文中，要么全部成功，要么全部失败
- 如果其中任意一列定义不合法（例如第二个字段用了当前版本不支持的
AFTER），那么整条 SQL 都会回滚，前面已经写出的列定义也不会真正生效 - 不要误以为“批量新增字段”就能规避大表变更风险——实际锁表时间仍然取决于最耗时的那个字段，通常是带
DEFAULT的大文本类型字段
很多人在实际执行 MySQL 新增字段操作时，最容易忽略的恰恰是这一点：即使写了 DEFAULT，在 MySQL 5.7 以及更早版本中，历史数据往往仍需要被逐行物理更新一次，用默认值完成回填，这通常会带来明显的 I/O 压力。直到 MySQL 8.0.12+ 引入“即时 DDL”之后，“新增带默认值字段”才更多地转向元数据层面完成。不过它也并非毫无限制，前提通常包括字段不能是 JSON、TEXT、BLOB 类型，同时也不能搭配 AFTER/FIRST 使用。因此，做 ALTER TABLE ADD COLUMN 优化时，不能只看语法是否正确，真正决定是否会卡顿、是否会锁表的，往往是 MySQL 版本、字段类型以及字段定义组合方式。
