上个月我接了一个听起来很简单的需求：给主库上一张两千多万行的订单表新增一个字段。这个任务在纸面上就是一条ALTER TABLE的事，但凡是操盘过千万级大表的人都明白，给这种量级的表加字段，真正的风险不在于 SQL 本身，而在于你对数据库内部机制有没有敬畏。这篇文章就按操作手册的标准来写：为什么加个字段能把实例搞挂、三种主流方案怎么选、动手前检查什么、pt-osc 全流程怎么跑，以及我踩过的几个真坑。适合正在带大表、准备做结构变更的 DBA 和负责核心表的后端同学参考。
先给结论：千万别在业务高峰期对千万级大表直接敲ALTER TABLE ADD COLUMN。这句话不是吓唬人，我见过不止一次，因为一条加列语句把实例 IO 打到 90% 以上、主从延迟飙到几百秒、接口大面积超时的案例。理解了背后原理，你才不会在遇到问题时慌乱，也不会被工具的输出日志带着走。
1. 加个字段为什么能把大表干趴：先弄清 ALTER 的底层逻辑
1.1 INPLACE 不等于"无代价"：它要重写整棵聚簇索引
很多人有个误区：MySQL 5.7 以后 ALTER 支持 INPLACE 算法，就以为修改表结构可以"不碰数据"了。实际上 INPLACE 只是说它不需要像老版本那样生成一个完整临时表再导数据，但对于新增字段这种操作，InnoDB 依然要把整张表的数据行逐行读出来、补上新列、再写回新的数据页，本质上等于把整栋楼的每一层都重新装修一遍。
拿我那两千万行的订单表举例，数据加索引总共 20GB 出头。哪怕 SSD 顺序写能跑到 100MB/s，光重写数据就得几分钟到十几分钟，期间 buffer pool 被大量新页挤占，原有热数据缓存命中率明显下降，磁盘 IO 也被持续占住。这种"温和的灾难"不会一下打死实例，但会让整体性能肉眼可见地下降。
提示：INPLACE 的意思不是"无操作"，而是"数据还是在原来的表空间里重写，不额外生成整表副本"。代价从行数、行宽、索引数量三个维度叠加，行数越多、行越宽、二级索引越多，重写越慢。
1.2 两颗隐形炸弹：MDL 锁等待与在线变更日志溢出
加字段真正致命的，往往不是数据重写本身，而是两个容易被忽略的机制。
第一是 MDL（元数据锁）。所有 DDL 语句开始前需要拿到表的元数据锁，结束的瞬间还需要一个极其短暂的排它锁来切换表定义。如果业务里有长事务、长查询正握着这张表的 MDL，你的 ALTER 就会卡在 "Waiting for table metadata lock"，而它后面所有访问这张表的 SQL 都会跟着排队。一次 DDL 排队，带来的是整个连接池的雪崩。
第二是在线变更日志。MySQL 的 online DDL 会把执行期间并发的 DML 增量记录在一个内存日志里，默认上限innodb_online_alter_log_max_size是 128MB。如果改表期间这张表的写入量太大，增量日志被撑爆，整个 ALTER 会直接报ERROR 1799 (HY000): DB_ONLINE_LOG_TOO_BIG。你在低峰期改表能成功，高峰期一改就爆，就是这个原因。
1.3 一次真实事故复盘：加列加出了主从延迟
我之前处理过的一次线上事故就很典型。同事在 5.7 实例上给一张 1800 万行的用户行为表加字段，直接在下午三点执行了ALTER TABLE ... ADD COLUMN ... NOT NULL DEFAULT 0。语句本身跑了 13 分钟完成，但执行期间实例 QPS 掉了三分之一，Threads_running从 30 一路涨到 200，主从延迟最高到了 90 秒，读多写少的业务开始大面积超时。
事后复盘原因很清楚：行重写占满了 IO 和 buffer pool，连接池里的查询开始堆积，而主库的每一个改动都要同步到从库串行回放，延迟自然被拉大。最讽刺的是，这个字段实际上第二天才被代码用到，完全可以在凌晨低峰期执行，甚至可以用工具限速跑。
1.4 千万级大表加字段，先记住这六类风险
- MDL 排队与雪崩：长事务卡住 DDL，后续所有 SQL 排队，接口超时。
- 主从延迟放大：主库重写数据 + 从库串行回放，延迟在变更期间显著拉高。
- 磁盘空间翻倍：pt-osc/gh-ost 都要建影子表，老表还要保留一段时间，空间需求超出预期。
- 无法秒级回滚：加完列再想删，等于再跑一次全表重写，"回滚"根本不快。
- 缓冲池与 IO 被挤占：大量页读写把热数据缓存打没，整体性能下降。
- 中途失败后的残留：工具中断后会留下影子表、触发器，清理不及时会影响后续操作。
2. 方案怎么选：直接 ALTER、pt-osc、gh-ost 的取舍
2.1 先看版本：8.0.12+ 的 INSTANT 是白送的机会
如果你的实例是 MySQL 8.0.12 及以上版本，加字段有一个近乎作弊的选项：ALGORITHM=INSTANT。这是纯元数据操作，只改数据字典，不碰数据页，秒级完成，对业务几乎零影响。
ALTER TABLE `orders` ADD COLUMN `user_tag` VARCHAR(32) NULL DEFAULT NULL COMMENT '用户标签', ALGORITHM=INSTANT, LOCK=NONE;当然 INSTANT 有限制：8.0.12 到 8.0.28 之间基本只能加在最后一列，压缩表、行格式受限、行大小超限等场景会直接报错；8.0.29 之后部分场景的支持范围进一步放宽。我的建议是：不管什么场景，先在测试实例上带上ALGORITHM=INSTANT跑一下，能成就是白捡的便宜；报错就老老实实往下看其他方案。
2.2 pt-osc：触发器方案为什么经典
Percona Toolkit 里的pt-online-schema-change是很多团队操作千万级大表的首选。它的思路可以概括成五步：
- 根据原表结构，创建一个带新字段的影子表（如
_orders_new）。 - 在原表上创建三个触发器（INSERT/UPDATE/DELETE），把变更实时同步到影子表。
- 按主键或唯一键分批（chunk）把原表数据拷贝到影子表，每批可限速。
- 拷贝完成后，用
RENAME TABLE在一条语句里完成新旧表切换。 - 删除触发器，默认还会把老表 drop 掉。
优点很清楚：对原表不加锁、可限速、成熟稳定、参数丰富。缺点同样明显——热点表上每个行变更都会额外触发一次对影子表的写，相当于把写放大了一倍；如果表上已经有触发器，它会直接拒绝执行；最后切换时那个短暂的元数据锁依然存在。
2.3 gh-ost：把触发器换成 binlog 消费
gh-ost是 GitHub 开源的方案，核心改进是不建触发器。它把自己伪装成一个从库，通过 binlog 获取原表上的增量变更，应用到影子表上。这样既不影响原表的写入路径，也没有触发器带来的写放大。
代价是硬性环境要求：binlog 必须开启且格式为 ROW，binlog_row_image必须是 FULL，执行账号需要有读取 binlog 的权限。它同样要求表有主键或唯一键。在从库上做预演、精确的限流配置（--max-lag-millis、--max-load、--throttle-control-replicas）是它比 pt-osc 细腻的地方。
2.4 三张表对比，照着选就行
| 维度 | 直接 ALTER（INPLACE/INSTANT） | pt-osc | gh-ost |
|---|---|---|---|
| 核心原理 | 重建聚簇索引 / 元数据修改 | 影子表 + 触发器 + 分批拷贝 | 影子表 + 消费 binlog |
| 对原表写入影响 | 在线日志缓冲并发 DML，重写占 IO | 触发器带来写放大 | 无额外写放大 |
| 环境要求 | 版本支持即可 | 必须有主键/唯一键，无冲突触发器 | 必须有主键/唯一键，binlog=ROW+FULL |
| 适用场景 | 小表低峰，或 8.0 走 INSTANT | 千万级大表日常首选 | 高频写表、对写放大敏感 |
| 主要风险 | 在线日志溢出、MDL 排队 | 触发器冲突、切换瞬间锁 | 环境不满足直接无法启动 |
我选方案的顺序很固定：8.0 先试 INSTANT；不行就看表有没有唯一键和现有触发器；高频写表优先 gh-ost，其余用 pt-osc；如果两个工具的环境条件都不满足，那就老实评估停机窗口。
3. 动手前的检查清单：别等执行到一半才发现没退路
3.1 磁盘容量是硬指标
任何影子表方案都意味着需要额外的磁盘空间。先搞清楚表当前占多大，再决定留多少余量：
SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS total_mb, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb FROM information_schema.tables WHERE table_schema = 'your_db' AND table_name = 'orders';执行期间影子表占一份空间，RENAME之后老表还占一份空间，binlog 因为 DDL 和增量事件也会变大。保守起见，我要求变更前剩余磁盘空间至少是当前表大小的 2 倍。我的习惯是变更期间每 5 分钟手动看一眼df -h，或者提前挂一个磁盘空间监控告警。如果是走 8.0 的 INSTANT，这块基本不用操心。
3.2 藏在表结构里的地雷：触发器、外键、字符集、唯一键
在真正执行之前，把这些事全部验证一遍：
- 主键/唯一键：pt-osc 和 gh-ost 都必须靠唯一键来切分 chunk，没有就直接报错。如果表确实没有任何唯一键，先单独立项补一个，别想绕过。
- 已有触发器：pt-osc 在探测到表上已有触发器时会直接拒绝执行。这不是 bug，是保护机制，因为触发器嵌套会让数据一致性变得不可控。
- 外键：两个工具处理外键关系都很麻烦，参数不同、行为不同。最稳妥的做法是变更前先确认这张表是否被外键关联，有关联就评估拆掉，或者改用官方 online DDL 在低峰执行。
- 字符集与排序规则：新列尽量和表内同类型列保持一致。VARCHAR 列字符集不一致，在 JOIN 时容易触发隐式转换，把本该走索引的查询打成全表扫描。
- 默认值语义：新增列如果是
NOT NULL且无默认值，已有行会被回填隐式默认值（字符串填''，数字填0）。如果业务预期是"新增列代表未设置"，这个回填就是一次数据事故。我一般优先写成NULL DEFAULT NULL，或者显式给出有业务含义的 DEFAULT。 - 行大小上限：InnoDB 单行有 65535 字节的限制，表已经很宽的时候再加列可能直接失败。TEXT/BLOB 大字段会让每次 chunk 拷贝更慢，评估耗时时要多留余量。
3.3 复制状态与窗口评估
工具跑起来之后，主从延迟会明显波动，所以动手前必须确认复制链路是健康的：
SHOW SLAVE STATUS\G -- 重点看三项：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master多个从库就逐个确认，任何一个从库上有延迟或异常，都不适合在这个时间点做变更。
窗口怎么选？不能拍脑袋说"凌晨没人"。我通常是拉最近一周的 QPS 曲线，把低谷时段挑出来，同时查一下有没有定时统计、归档任务撞在同一时段。和业务方提前打好招呼，变更期间如果有问题，应用侧要有降级开关能先摘流量。
3.4 回滚预案：新增字段也要留后路
一个容易忽略的事实：加完字段后想"回滚"，意味着要再跑一次DROP COLUMN，这同样是一次全表重写，根本做不到秒回。所以回滚预案的核心不是"期望删得快"，而是"万一有问题，能把旧数据快速顶上"。
我的标准做法是：
- 云上实例就先打个磁盘快照，这是成本最低、最可靠的兜底。
- pt-osc 执行时加
--no-drop-old-table，gh-ost 不加--ok-to-drop-table，把老表保留 24 小时。 - 变更前把
SHOW CREATE TABLE的输出和当前行数记下来，作为变更后的对账基线。
4. pt-osc 全流程实操：一条命令背后的每个环节
4.1 安装清单与最小权限
pt-osc 在 percona-toolkit 包里，装好即可：
# Debian/Ubuntu 系 sudo apt install percona-toolkit # CentOS/RHEL 系 sudo yum install percona-toolkit账号权限不用给超级管理员，但要覆盖工具的全部操作：
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, TRIGGER ON `your_db`.* TO 'ddl_worker'@'%';另外建议补上PROCESS和REPLICATION CLIENT权限，方便工具发现从库并检查延迟。如果账号连不到从库，--max-lag的检查可能直接失效，等于少了一层保护。
4.2 核心参数逐个拆解
--alter：真正要执行的 DDL 变更语句，注意不要包含ALTER TABLE前缀。--chunk-size：每个批次拷贝的行数，默认 1000。表行宽、有 TEXT/BLOB 时调小到 500 更稳。--max-lag：主从延迟超过多少秒就暂停拷贝，默认 1 秒偏保守，我一般给 5~10 秒，避免频繁暂停拖长整体时间。--max-load：实例负载超过阈值暂停拷贝，低于阈值恢复，示例Threads_running=60。--critical-load：超过阈值直接中止操作，示例Threads_running=100，按实例核数和历史峰值的 70% 估算。--check-interval：检查负载和延迟的间隔，默认 1 秒。--dry-run：只做校验，不真正执行，第一次跑必加。--execute：真正执行变更。--no-drop-old-table：切换后保留原表（重命名为_old后缀），我永远带着它。--recursion-method：从库发现方式，默认走 processlist，复杂拓扑可以用 dsn 方式。
4.3 先干跑：dry-run 与小表测速
正式动生产之前，至少做两层验证。第一层是 dry-run：
pt-online-schema-change \ --host=10.0.0.1 --user=ddl_worker --password=xxx \ --alter="ADD COLUMN user_tag VARCHAR(32) NULL DEFAULT NULL COMMENT '用户标签'" \ D=your_db,t=orders --dry-run这一步会校验 SQL 合法性、表结构、触发器、唯一键等，把潜在问题全部暴露出来。第二层是测速：在一台克隆实例或从库上，把 orders 表按主键前 10% 的行复制成orders_test，跑一遍同样的变更计时。比如 10% 的数据用了 3 分钟，那全表大约 30 分钟，再乘 1.5 留出余量，用这个时间去申请变更窗口。
4.4 正式执行与实时盯盘
确认没有问题后，把 dry-run 换成 execute：
pt-online-schema-change \ --host=10.0.0.1 --user=ddl_worker --password=xxx \ --alter="ADD COLUMN user_tag VARCHAR(32) NULL DEFAULT NULL COMMENT '用户标签'" \ --chunk-size=2000 --max-lag=10 \ --critical-load Threads_running=100 --max-load Threads_running=60 \ --no-drop-old-table --execute \ D=your_db,t=orders执行期间我不会只盯着终端，而是开四个监控窗口：
SHOW PROCESSLIST看 chunk 的 SELECT/INSERT 是否正常推进，有没有卡在 "Waiting for table metadata lock"。df -h每 5 分钟确认磁盘余量没有异常下降。SHOW SLAVE STATUS\G看从库延迟是否在--max-lag控制范围内。- 工具自身输出的
Copying your_db.orders: 40% 05:30 remain一类进度信息，作为整体节奏的参考。
如果中途因为--critical-load触发而中止，别急着重跑。先把残留清干净再定位原因：
DROP TABLE IF EXISTS `your_db`.`_orders_new`; DROP TRIGGER IF EXISTS `your_db`.`pt_osc_your_db_orders_ins`; DROP TRIGGER IF EXISTS `your_db`.`pt_osc_your_db_orders_upd`; DROP TRIGGER IF EXISTS `your_db`.`pt_osc_your_db_orders_del`;清完后看是参数阈值给太低，还是真的撞上了业务高峰，调整后再执行。
4.5 变更后的收尾检查
RENAME完成不等于流程结束。我每次都会做四件事：
SHOW CREATE TABLE orders确认新字段在，且注释、默认值、字符集正确。SHOW TRIGGERS确认工具创建的三个触发器已经被清理。- 行数对账：拿变更前记录的行数快照和现在的
COUNT(*)对比，有差异说明拷贝丢行，必须立刻介入。 - 抽查几行数据，看新列的默认值是否符合业务预期。
老表先留着，24 小时内不要动。确认业务稳定、代码发版无误之后再在低峰期DROP TABLE orders_old。别小看这个 drop，大表删除在 8.0 里也可能在后台持续一段时间，同样要避开高峰。
5. 踩坑实录：四个翻车现场与操作铁律
5.1 已有触发器，pt-osc 直接拒单
第一次跑 pt-osc 的时候，工具在预检阶段就直接退出，提示表上已经有触发器。当时那张表确实挂着两个业务触发器，pt-osc 认为它无法安全地叠加自己的触发器。解决方案有两种：评估触发器是否可以下线；如果必须保留，就改用 gh-ost，它不依赖触发器所以不受影响，但前提是 binlog 格式满足要求。
5.2 表没有主键/唯一键，chunk 无从切起
另一个常见报错是找不到主键或唯一键。工具要靠它切分 chunk，没有就直接罢工。表本身没有唯一键的问题很难绕过去，我的处理是：先在低峰期给表补一个合适的唯一键（本身也是一次 DDL，单独排计划），然后再做加字段。硬着头皮让工具硬跑，只会换来一个执行到一半的失败现场。
5.3 binlog 不是 ROW，gh-ost 直接撂挑子
gh-ost 对环境很敏感，binlog 不是 ROW 或者binlog_row_image不是 FULL，它会直接报错拒绝启动。遇到这种情况，先执行SHOW VARIABLES LIKE 'binlog_format'和SHOW VARIABLES LIKE 'binlog_row_image'确认。调整这两个参数会影响整个实例的复制行为，不能为了一个变更随意改全局配置。如果环境确实不支持，就退回 pt-osc，或者在维护窗口统一整改 binlog 配置。
5.4 直接 ALTER 时在线日志爆掉
有一次我在低峰期用官方 online DDL 给一张中等大小的表加索引，结果并发写入稍微一多，就报出DB_ONLINE_LOG_TOO_BIG。原因就是 1.2 里说的 128MB 在线日志被并发 DML 撑爆。临时解法是调大参数：
SET GLOBAL innodb_online_alter_log_max_size = 1073741824;但治本的方法还是错峰，或者干脆用 pt-osc/gh-ost。它们分批拷贝，不依赖这个在线日志，对并发的容忍度高得多。这也是我在千万级大表场景下不推荐直接 ALTER 的重要原因。
5.5 我自己的几条铁律
- 版本优先：8.0.12 以上，先试
ALGORITHM=INSTANT，能省掉后面所有麻烦。 - 工具不是免死金牌：上工具之前该做的预检一项都不能少，尤其是磁盘、唯一键、复制状态。
- 磁盘按 2 倍预留：变更中每隔几分钟看一眼磁盘，空间耗尽比锁等待更难收场。
- 新列允许 NULL 或显式默认值：不要把数据语义交给隐式回填去赌。
- 老表保留 24 小时：这 24 小时内谁喊回滚都有救，过了统一清理。
- 变更当发布：有窗口、有监控、有通知、有预案，做完有复盘记录。
最后分享一个我每次都会做的小事：加列前把information_schema.tables里该表的行数、data_length、index_length存到变更记录里，变更后拿COUNT(*)和空间量级对一遍账，行数和空间都能对上，基本可以确认影子表拷贝没丢行。数据库里的坑大多是重复的，每次大表变更完，把耗时、卡点、磁盘峰值简单记到文档里，手册越写越厚，以后再遇到千万级大表新增字段，就真的只是按流程走一遍的事。
