3800万行大表白天高峰加复合索引：gh-ost、pt-osc 还是原生 INPLACE？

背景：MySQL 8.0.32，InnoDB，单表 order 约 3800 万行（约 95GB），1 主 2 从半同步（rpl_semi_sync_master_wait_for_slave_count=1），白天高峰 QPS 约 800，业务侧要求 P99 < 200ms。

现象：一条慢查询 SELECT id, status, create_time FROM order WHERE tenant_id=? AND status IN (1,2,3) ORDER BY create_time DESC LIMIT 50，当前 P99 约 1.4s，EXPLAIN 显示 type=ALL、rows≈3800 万；加 (tenant_id, status, create_time) 复合索引后 EXPLAIN 预估 rows≈200，预期 P99 能降到 5ms 内。

已尝试的排查与结果：

1. 直接 ALTER TABLE ... ADD INDEX，ALGORITHM=INPLACE, LOCK=NONE，跑了 4 小时 20 分，业务没崩但 IO util 长期 95%+，从库 lag 一度 11s，被 SRE 叫停；
2. pt-online-schema-change 在凌晨低峰跑了一次，1 小时 50 分，但触发器回放阶段在 800 QPS 下把从库 lag 推到 6s，被拦下；
3. 考虑 gh-ost，但内部 DBA 说"3800 万行用 gh-ost 不放心，怕 binlog 解析卡顿"，没敢上。

期望得到的答案形态：

1. gh-ost / pt-osc / 原生 INPLACE 三者在「800 QPS + 半同步」场景下的实测代价（IO util、复制 lag、业务 P99 抖动），最好能给关键参数（chunk size、dml_batch_size、throttle 策略）；
2. 有没有"加索引前先做数据治理"的中间方案（例如把 90 天前的冷数据归档到冷表后再加索引），以及归档本身的代价评估方法；
3. 索引加完之后，对 INSERT/UPDATE 的写放大怎么量化评估（特别是 status 字段高频更新时），有没有可复用的基准脚本或指标。

补充：我倾向"先治理数据、再加索引"，但团队里有人觉得"治理成本更高，不如直接 gh-ost 硬上"，想听听社区里在 1 亿行以下、白天高峰、半同步复制场景下，大家是怎么权衡这三条路的。