mysql中add column语法错误会直接报错，需严格指定类型、正确使用after/begin（8.0.19+）、谨慎处理default与not null约束，并注意版本差异及应用层同步。
ALTER TABLE ADD COLUMN 语法写错会直接报错
MySQL 对 ADD COLUMN 的位置、类型和约束写法很敏感，少个关键字或顺序不对就会触发 ERROR 1064 或 ERROR 1068。最常见的是把 AFTER 写成 BEFORE（MySQL 8.0.19+ 才支持 BEFORE），或者漏掉字段类型。
实操建议：
- 必须明确指定数据类型，比如
VARCHAR(255)、INT、TINYINT UNSIGNED，不能只写name - 想控制字段位置，用
AFTER existing_column；不加位置默认加在最后 - 如果表很大（千万级行），
ADD COLUMN会锁表（尤其 MySQL 5.6 及更早版本），线上操作前务必确认维护窗口 - 示例：
ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 1 AFTER email;
DEFAULT 值和 NULL 约束容易被忽略
新字段如果没有显式声明 NOT NULL，MySQL 默认允许 NULL；但一旦加了 NOT NULL 又没给 DEFAULT，已有行就无法填充值，直接报错 ERROR 1138。
实操建议：
- 新增
NOT NULL字段时，必须同时提供DEFAULT（哪怕只是DEFAULT ''或DEFAULT 0） - 如果业务上确实不允许空值，且历史数据需统一初始化，先加允许 NULL 的字段，再用
UPDATE填充，最后MODIFY COLUMN改为NOT NULL -
DEFAULT值类型必须和字段类型兼容，比如DEFAULT '2024-01-01'对DATETIME合法，对INT就非法
MySQL 版本差异影响 ADD COLUMN 行为
MySQL 5.6、5.7 和 8.0 在在线 DDL 支持上差别很大。老版本加字段基本等于全表拷贝，耗时长、锁表久；8.0.12+ 引入 instant DDL，部分场景能秒级完成——但仅限于加字段且不指定位置或不带 DEFAULT 的极简情况。
实操建议：
- 查当前版本：
SELECT VERSION(); - MySQL 8.0.12+ 想走 instant，只能用：
ADD COLUMN col INT（无DEFAULT、无位置约束、非生成列） - 只要写了
DEFAULT或AFTER，哪怕 8.0 也会退化为 inplace（快于 copy，但仍需重建二级索引） - 生产环境别赌“应该很快”，先在同规格从库上试一次
ALTER看耗时
添加字段后应用代码没同步会出隐性问题
字段加成功不代表万事大吉。ORM（如 Laravel Eloquent、Django ORM）或手写 SQL 如果没更新模型定义或查询语句，可能继续忽略该字段，甚至因 SELECT * 缓存导致旧逻辑读到 NULL 值而崩溃。
实操建议：
- 加字段后立刻检查所有涉及该表的 DAO 层、DTO、序列化逻辑，补上新字段映射
- 避免在关键路径用
SELECT *，尤其字段数多或有变更预期的表 - 如果字段是必填业务属性，加完别忘了改应用层校验（比如 API 入参验证、前端表单规则）
- 注意迁移顺序：DB 变更 → 应用灰度发布 → 观察日志/监控 → 确认无
NULL相关报错再全量
