大表加字段与索引：online DDL 注意事项

一张几千万行的大表，加字段的方式不对，执行的瞬间就能把业务拖住。online DDL（在线表结构变更）解决了大部分锁表问题，但"online"不等于没有代价，几个前提要先弄清。 什么情况会锁表 MySQL 5.6 起，加字段、加二级索引多数走 INPLACE 方式，允许并发读写。但不是所有变更都友好：改列类型、改字符集、缩短字段长度，往往退化成 COPY（建新表拷数据）甚至锁写。执行前显式声明方式，是最实用的自我保护： ALTER TABLE bigtable ADD COLUMN remark VARCHAR(200), ALGORITHM=INPLACE, LOCK=NONE; 引擎不支持这个方式时会直接报错，而不是悄悄退化成锁表操作——报错可以重选时机，悄悄锁表只能看着业务挂。 代价在哪里 即便走 INPLACE，重建期间磁盘上也要同时放得下新旧两份数据，主从架构下变更以大事务形式同步，从库延迟会明显抬升。真正伤业务的往往不是主库，而是从库延迟引发的读旧数据连锁反应。执行时长随表大小线性增长，千万行表跑几十分钟很常见。 低峰窗口与预检 动手前定三件事：磁盘余量大于表体积一倍；时间选业务低峰（是不是凌晨要看自己的监控曲线，别照抄别人家）；通知值班同事留人盯从库延迟。主从架构可以先在从库执行一遍，量出实际耗时，心里有数再动主库。 pt-osc 一句带过 变更频繁、表持续增长的业务可以了解 pt-online-schema-change 这类工具：建影子表、用触发器同步增量、原子改名收尾，全程几乎不阻塞。工具自身也有触发器开销和切换风险，先在测试环境完整演练，别第一次使用就冲生产核心表。 大表变更是高危操作，把"显式声明算法、算好磁盘、选对窗口、留好回退"固化成流程，比每次临场发挥可靠得多。