生产环境大表新增字段的风险与最佳实践

一、为什么要谨慎对待生产 DDL（尤其是大表）

表结构变更（DDL）在生产环境不可避免。但在千万级/亿级大表上跑原生 ALTER TABLE，代价可能很高：

可能触发长时间 MDL（metadata lock），导致读写阻塞、请求超时；
某些场景会退化为 表拷贝（COPY），吞吐骤降、I/O 飙升、空间瞬涨；
异常中断时 回退困难，容易引发连锁事故。

建议不在生产上直接用 MySQL 原生 DDL，优先选用 在线 Schema 变更工具 来降低风险。

二、典型事故回顾（缩写版）

在核心大表aigc_lesson上执行：

ALTER TABLE aigc_lesson ADD error_message TEXT NULL COMMENT '错误信息';

执行期间数据库整体变慢、部分请求超时。根因：不同 MySQL 版本/引擎特性下，添加TEXT/BLOB字段常会触发表重建或重写，形成长时间锁与 I/O 压力。

类型、位置、版本都影响算法路径；看似”在线”的 DDL，条件不满足时就会退化为 COPY。

三、原生 DDL 的不确定性

算法不可控：ALGORITHM=INPLACE/INSTANT的可用性强依赖版本与具体变更；条件不满足时会退化为COPY。
大字段风险更高：TEXT/BLOB等类型在不少组合场景下难以真正在线，极易触发表重建。
失败成本高：执行中断或失败，回滚与清理代价大；长时间阻塞期间，业务易雪崩。

如果必须走原生 DDL，请确保版本明确且在测试环境验证 “会因 INSTANT/INPLACE 成功、且 LOCK=NONE”，否则不要在生产尝试。

四、推荐做法：工具化在线变更

方案 A：pt-online-schema-change（pt-osc）

原理：建影子表 → 触发器同步增量 → 分批拷贝历史数据 → 原子切换表名。优点：业务可写、锁极短、可限速、可随时暂停/中止。

示例命令（可直接套用并按需微调）：

pt-online-schema-change \
  --alter "ADD COLUMN error_message TEXT NULL COMMENT '错误信息'" \
  --execute \
  --user=root --password='***' --host=127.0.0.1 --port=3306 \
  D=mydb,t=aigc_lesson \
  --charset=utf8mb4 \
  --chunk-time=0.5 \
  --max-load Threads_running=50 \
  --critical-load Threads_running=100 \
  --check-interval=2

小贴士：先跑--dry-run验证流程，再用--execute正式执行；业务繁忙时可调小--chunk-time或收紧--max-load。

方案 B：gh-ost

原理：通过 binlog 捕获增量变化（非触发器），对大表影响更小、灰度能力更强。常见前提：binlog 开启、权限与复制链路允许读取 binlog（详情以各自环境为准）。

示例命令：

gh-ost \
  --user="root" \
  --password="***" \
  --host="127.0.0.1" \
  --database="mydb" \
  --table="aigc_lesson" \
  --alter="ADD COLUMN error_message TEXT NULL COMMENT '错误信息'" \
  --allow-on-master \
  --max-lag-millis=1500 \
  --cut-over=default \
  --exact-rowcount \
  --conflict-free-interval=5s \
  --execute

小贴士：先在从库或影子环境做演练（如用--test-on-replica等组合思路），确认复制延迟与切换行为可控。

五、工具化对比速览

维度	MySQL 原生 DDL	pt-osc / gh-ost
锁表风险	高，可能长时间锁	极低，仅切换瞬间需短锁
线上影响	不可控，退化 COPY 极痛	可限速，可暂停，影响可控
空间与 I/O	可能倍增	可平滑迁移、渐进占用
监控与止损	缺乏	自带限流/中止/进度监控
TEXT/BLOB	易触发表重建	更稳，仍需演练与监控

六、落地流程（一页清单）

上线前

评估影响：行数、数据量、索引、存储/磁盘余量、复制延迟预算

SELECT table_schema, table_name,
       data_length + index_length AS bytes
FROM information_schema.tables
WHERE table_schema='mydb' AND table_name='aigc_lesson';

演练验证：测试环境用相同版本、相同变更跑完整流程（含切换）
窗口选择：预约低峰时段，冻结相关发布与批处理

执行中

限速与阈值：设置--chunk-time/--max-load/--max-lag-millis
三件事盯紧：QPS/RT、复制延迟、数据库负载（CPU、I/O、Threads_running）
出现异常：立即暂停/中止，确认未切换则原表仍对外，数据安全

执行后

一致性复核：行数/校验抽样、核心查询对比
观察期：至少覆盖业务高峰一个周期
清理收尾：影子对象与临时资源检查

七、何时谨慎考虑原生 DDL（少数场景）

版本已明确支持目标变更的ALGORITHM=INSTANT或INPLACE+LOCK=NONE；
变更仅追加末尾可空列、无触发行重写；
在测试环境用相同版本验证不会退化，并能 fail-fast（例如指定ALGORITHM=INSTANT, LOCK=NONE以不满足即失败）。

即便如此，仍建议先演练并在低峰执行。

八、常见坑位与规避

长事务/大事务：会拉长 MDL 与复制延迟；执行前清理/规避长事务。
批量写入冲突：限速过小或切换时点不当，可能抖动；提前沟通业务窗口。
监控缺失：没有针对延迟与错误率的告警门槛，问题发现滞后。
空间预估不足：影子表拷贝期间空间占用上升；至少预留 1× 表大小的空间冗余（按实际工具策略留足）。

九、总结

不要盲目依赖原生 Online DDL：版本/场景不确定性很大，TEXT/BLOB 尤其危险。
生产大表优先用在线变更工具（pt-osc / gh-ost），借助影子表 + 增量同步实现可限速、可暂停的平滑迁移。
标准化流程：先演练 → 定窗口 → 有阈值 → 可回退 → 有监控。
把验证和可控放在第一位。