4200 万行 InnoDB 表在线加二级索引：native DDL vs gh-ost vs pt-osc，锁窗口与写入开销怎么估

背景： 我负责一套订单系统，核心表 t_order 约 4200 万行、单表含所有二级索引约 18GB，InnoDB，MySQL 8.0.32，单主单从。业务写入 QPS 日常 800~1200（以 INSERT 为主，少量 UPDATE status），峰值 2000。主从延迟容忍 < 5s。现在需要在线新增一个二级索引 idx_merchant_status (merchant_id, status)，业务方要求锁表窗口 ≤ 1s，最好 0 行锁。

现象与卡点： 之前在 800 万行 / 3GB 的表上用 ALTER TABLE ... ADD INDEX ... ALGORITHM=INPLACE, LOCK=NONE 加过索引，实际表现：索引构建约 40 分钟，期间 DML 正常但 P99 涨了约 30%；最后 commit 阶段有一次 ~800ms 的 MDL 等待（当时恰好有一个 3s 的慢 SELECT 没跑完）。整体可接受，但这次是 5 倍量级，我不确定：

1. 索引构建阶段 InnoDB 的后台线程（index merge / page allocation）会不会把在线 DML 的 P99 推高到不可接受？
2. 如果构建期间恰好有一个长事务（比如一个 10s 的报表查询），commit 阶段的 MDL 等待会不会把锁窗口撑到秒级以上？有没有办法在 DDL 前主动"清理"长事务？
3. 主库 apply 阶段，从库的复制延迟会不会超过 5s？

已尝试的排查：

• 查了 MySQL 官方文档：INPLACE + LOCK=NONE 理论上不阻塞 DML，但 commit 阶段需要获取 EXCLUSIVE MDL，如果此时有活跃事务就会等待；
• 看了 gh-ost 文档：用触发器镜像写入到影子表 + 最后原子 rename 切换，不依赖 MDL 窗口；
• 看了 pt-osc：原理类似（影子表 + 触发器 + 最后 rename），但 chunk 切分和 throttle 策略不同；
• 没找到社区里有同量级（>4000 万行）的实际 DDL 执行经验帖。

期望得到的答案形态：

1. 4200 万行 / 18GB 这个量级，三种方案（native DDL / gh-ost / pt-osc）的实际锁窗口预估（不是文档理论值，是跑过的经验值，哪怕是同量级的也行）；
2. gh-ost 的触发器模式在 800~2000 QPS 下，每条 DML 的额外开销大概多少（延迟 or CPU）？会不会把写入 P99 推高 20% 以上？
3. 有没有一个可操作的量化判断标准：比如「单表 > X 行 / > Y GB / 写入 QPS > Z」就该从 native DDL 切到 gh-ost？
4. 如果最终选 gh-ost，chunk-size、max-lag-millis、throttle 参数在 18GB 表上推荐怎么配？