直接执行alter table add column在千万级以上大表上极大概率导致长时间锁表、服务中断或主从延迟飙升，本质是架构风险而非性能问题；其安全性取决于能否承受写入阻塞、数据一致性缺口和磁盘空间翻倍压力。
直接执行 ALTER TABLE ADD COLUMN 在超大表（千万级以上）上极大概率导致长时间锁表、服务中断或主从延迟飙升——这不是性能问题，而是架构风险。是否“安全”，取决于你能否承受写入阻塞、数据一致性缺口和磁盘空间翻倍的压力。
为什么 ALTER TABLE ADD COLUMN 在大表上会卡住？
MySQL 的 DDL 行为与版本强绑定，老版本（5.6 之前）全程排他锁；5.6+ 虽支持 Online DDL，但一旦加了 DEFAULT、AFTER 或字段类型带约束，就会退化为 INPLACE 模式，仍需重建二级索引、扫描全表元数据，甚至触发临时日志膨胀。
- 1000 万行、单行 1KB 的表，在 SSD（500MB/s）上仅拷贝数据就要约 20 秒——这 20 秒内所有
INSERT/UPDATE都在排队等待 -
ALGORITHM=INPLACE, LOCK=NONE只对“最简新增”生效：比如ADD COLUMN id BIGINT（无默认值、无位置指定、非生成列） - 即使成功，从库回放该 DDL 是单线程的，50GB 表可能带来 15 分钟以上复制延迟
线上环境首选：pt-online-schema-change 零写入阻塞
Percona Toolkit 的 pt-online-schema-change 是目前生产环境最成熟的大表变更工具，它不依赖 MySQL 版本，靠触发器捕获实时变更，实现真正意义上的“业务无感”。
- 必须提前安装依赖：
perl-DBD-MySQL、perl-TermReadKey、perl-Digest-MD5 - 核心命令要带
--execute才真正执行，测试阶段先用--dry-run或--print - 务必加限速参数，避免 IO 打满：例如
--max-load="Threads_running=25"、--chunk-time=0.5 - 注意触发器权限：操作用户需有
TRIGGER、ALTER、DROP、INSERT、UPDATE、DELETE权限
示例：
pt-online-schema-change \ --alter "ADD COLUMN status TINYINT DEFAULT 0 AFTER email" \ D=your_db,t=orders \ --execute \ --chunk-time=0.3 \ --max-load="Threads_running=20"
如果不能装第三方工具，用原生“影子表 + 分批迁移”
当无法部署 pt-osc 或 gh-ost（如某些金融私有云环境），可手动走影子表流程，但必须规避两个致命坑：主键/索引拖慢 INSERT ... SELECT；实时写入丢失。
- 建影子表时立刻删掉主键和所有索引：
ALTER TABLE orders_new DROP PRIMARY KEY，等数据导入完再加 - 迁移数据必须分批，用主键范围切片（别用
LIMIT）：INSERT INTO orders_new SELECT * FROM orders WHERE id BETWEEN 1 AND 100000 - 最后一步
RENAME TABLE是原子操作，但要在业务低峰期执行，且确保应用层已做好双表兼容（比如字段名 fallback） - 迁移期间新写入的数据，需靠应用层双写或 binlog 解析补漏——这点常被忽略，导致线上丢数据
容易被忽略的细节：DEFAULT 值类型必须匹配字段类型
加字段时随手写 DEFAULT '0' 给 INT 字段，或 DEFAULT 0 给 DATETIME，MySQL 不报语法错，但在填充历史行时直接抛 ERROR 1292（truncated incorrect value），导致整个 DDL 失败回滚。
-
TINYINT→DEFAULT 0合法，DEFAULT '0'也合法（隐式转换） -
DATETIME→ 必须是DEFAULT CURRENT_TIMESTAMP或DEFAULT '2026-01-01 00:00:00'，写DEFAULT 0就失败 - 线上已有 NULL 值字段，新加
NOT NULL约束却没给DEFAULT，会触发ERROR 1138：“invalid use of NULL value”
真正麻烦的不是语法，是字段语义落地时，DEFAULT 值是否符合业务逻辑——比如给 is_deleted 加 DEFAULT 0 没问题，但给 created_at 加 DEFAULT '1970-01-01' 就可能污染下游报表。
