5 亿行核心表加索引，pt-osc / gh-ost / 原生 Online DDL 到底怎么选？

背景：我们有一张 5.2 亿行的订单表（InnoDB，单主 MySQL 8.0.35，16C128G），日均写入 QPS 约 2000，读 QPS 约 8000。现需新增复合索引 idx_uid_status_created (uid, status, created_at)，支撑新上线的「按用户+状态+时间范围」查询场景。

现象：我对比了三种方案的文档和社区文章，但实际决策时卡住了：

1. 原生 Online DDL（ALGORITHM=INPLACE, LOCK=NONE）：文档说无锁，但「复制延迟」和「binlog 放大」这两个指标我没有可参考的 5 亿行级实测数据；
2. pt-online-schema-change：社区普遍说它对主库压力更小，但对「有触发器/外键的表」不友好，我们的表恰好有 2 个 AFTER INSERT 触发器；
3. gh-ost：号称对主库零额外锁，但需要 binlog 回放，我担心在 2000 写入 QPS 下回放速度追不上。

已尝试：

• 在测试库（数据量 1/10，约 5000 万行）跑了原生 Online DDL，耗时 47 分钟，期间主库 CPU 峰值从 35% 升到 72%，未触发锁等待；
• 看了 pt-osc 的 --chunk-time 和 --max-lag 参数文档，但不确定在 5 亿行 + 有触发器场景下 chunk 大小该设多大才安全；
• gh-ost 的 benchmark 报告多为小表（< 5000 万行）数据，找不到大表参考。

期望得到的答案形态：

• 如果可能，给一个「表行数 × 写入 QPS × 是否有触发器」的决策矩阵或经验公式；
• 或者至少给一个你亲历的 5 亿行级加索引的完整时间线（开始→复制延迟峰值→完成），以及你选了什么方案、为什么；
• 不排斥「先分批 backfill + 最后一次性 ALTER」的折中方案，但请说明在什么条件下这个折中是安全的（比如触发器、主从一致性窗口）。