MySQL ADD COLUMN 必须指定数据类型，否则报错；需注意锁表风险、默认值填充阻塞、时区与版本兼容性、外键及SELECT *依赖等线上隐患。
ALTER TABLE ADD COLUMN 语法必须带数据类型
MySQL 不允许像某些 NoSQL 那样“先加空字段”，ADD COLUMN 必须明确指定类型，否则报错 ERROR 1167 (HY000): Key column 'xxx' doesn't exist in table（常见于误写成 ADD COLUMN name 而漏掉类型）。
实操建议：
- 基础写法：
ALTER TABLE table_name ADD COLUMN column_name VARCHAR(255) AFTER existing_column; - 如果字段允许 NULL，显式写上
NULL或NOT NULL；不写默认是NULL，但依赖 MySQL 版本和 sql_mode，建议不省略 -
AFTER和FIRST控制位置，不写则追加到末尾；线上表慎用FIRST，可能影响已有 SELECT * 逻辑（虽不推荐，但真实存在） - 大表加字段会锁表（尤其 MySQL 5.6 及以前），8.0+ 支持
ALGORITHM=INPLACE，但仅限部分场景，不能假设一定不锁
给有默认值的字段加 NOT NULL 很危险
执行 ALTER TABLE t ADD COLUMN c INT NOT NULL DEFAULT 0; 看似安全，但如果表已存在百万行，MySQL 仍要逐行填默认值 —— 这个过程会阻塞 DML，且可能触发磁盘爆满（临时文件 + redo log 增长）。
实操建议：
- 先加可空字段：
ADD COLUMN c INT - 再分批更新值（如按主键范围），避免长事务
- 最后用
MODIFY COLUMN或CHANGE COLUMN加NOT NULL约束 - 注意：MySQL 8.0.13+ 支持
ADD COLUMN ... DEFAULT … STORED的虚拟列方式绕过填充，但只适用于计算场景，非通用解法
datetime 类型字段加默认值要小心时区和版本差异
写 ADD COLUMN created_at DATETIME DEFAULT NOW() 在 MySQL 5.6 会报错，因为老版本只允许 TIMESTAMP 用函数默认值；5.7+ 才支持 DATETIME 的 CURRENT_TIMESTAMP 类默认值，但行为仍有坑。
实操建议：
- 统一用
CURRENT_TIMESTAMP（不是NOW()），它在 INSERT 时自动取当前时间，且受时区变量影响 - 如果需要创建时自动填、后续不更新，加
ON UPDATE CURRENT_TIMESTAMP就错了 —— 那会导致 UPDATE 行时也被改 - 想让字段“只创建时设、之后不变”，就只写
DEFAULT CURRENT_TIMESTAMP，别加ON UPDATE - 确认服务器
time_zone设置，否则默认值可能比你预期早/晚 8 小时
线上表加字段前必须检查外键和索引依赖
看起来只是加一列，但如果原表被其他表用 FOREIGN KEY 引用，或有触发器、视图、存储过程里写了 SELECT *，加字段可能引发隐性故障。
实操建议：
- 查外键：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table'; - 查视图定义：
SHOW CREATE VIEW view_name;，确认没硬编码字段顺序 - 禁止在生产环境对被
SELECT *消费的表直接加字段，除非你能控制所有调用方 - 如果用了 ORM（如 Django、Rails），加字段后必须同步迁移模型，否则 ORM 可能把新字段当 NULL 插入，或抛
Unknown column错误
事情说清了就结束。加字段不是原子操作，每个细节都可能卡在线上——尤其是默认值填充、锁表现、依赖链这三块，最容易在凌晨三点报警。
