线上大表 DDL 变更：pt-osc、gh-ost 还是原生 Online DDL，到底怎么选

背景：我做了 15 年 DBA，线上大表（几千万到几亿行）加字段、改字段类型、加索引这类 DDL，是出事故最高频的场景之一。MySQL 原生 Online DDL（5.6+）在"加列/加索引"这类 instant/inplace 操作上确实已经够用，可一旦碰上"改字段类型""重建表"，或者表上有长事务、高并发写入，原生方案照样能把主从延迟顶爆、把 binlog 刷到磁盘满。于是社区里就分化出几条路线，我见过每种都有人踩坑，也想听听大家的真实取舍。

常见分歧（四种做法）：

1. 纯原生 Online DDL：信 MySQL 自己，靠 ALGORITHM=INPLACE + LOCK=NONE，省事、不引第三方，但遇到 rebuild 类变更基本裸奔，大表上风险不可控。
2. pt-online-schema-change（pt-osc）：触发器截获写入 + 影子表，逻辑成熟、参数可控，但触发器本身在高并发下会放大写延迟，而且它对复制环境不友好，主从链路里要小心。
3. gh-ost：不碰触发器，靠解析 binlog 追增量，对主库压力最小，这也是我目前最偏爱的方案；代价是它依赖 binlog 格式（ROW）、配置偏多，且对 GTID、半同步这些细节敏感，部署门槛比 pt-osc 高。
4. 影子表 + 业务双写/切流：把变更彻底搬出数据库层，由应用配合，适合超大表或跨库迁移，但工程量大、容易双写不一致。

我的倾向：默认用 gh-ost，因为它对主库侵入最小、能限速、可暂停，适合生产；pt-osc 作为备选（某些 gh-ost 起不来的环境）；纯原生只用于确定是 instant/inplace 且表不大、无长事务的场景。核心原则就一条——任何 DDL 都要"可限速、可暂停、可回滚（至少可终止）"，达不到就别上。

想听大家聊聊：

• 你们线上 DDL 实际用的是哪套？为什么，踩过什么坑？
• gh-ost 对 binlog / GTID / 半同步的坑，谁有具体配置可以分享？
• 多大的表你们会直接放弃在线 DDL，转影子表 + 双写？有没有一个"经验阈值"？
• 主从延迟你们怎么设上限（chunk 大小、sleep 参数）？给个具体数值参考也行。

欢迎直接贴你的配置和事故复盘，越具体越好。