2 亿行大表在线加覆盖索引：INPLACE 期间写延迟到底涨多少、怎么判停

背景：MySQL 8.0.36，InnoDB，订单主表 order 约 2 亿行、约 400GB 数据文件，buffer pool 256GB，业务读写比约 7:3，高峰期 TPS 约 8000（写约 2400）。现在要治理一条按 (status, create_time, amount) 过滤 + 回表的慢查询，EXPLAIN 显示需要一条覆盖索引 idx_status_ct_amt (status, create_time, amount)。直接 ALTER TABLE ADD INDEX，我担心的是落地成本而不是能不能做。

现象 / 我的担忧：用 ALGORITHM=INPLACE, LOCK=NONE 在线加索引时，社区说法不一——有人说写路径几乎无感，有人说因为要维护索引树 + 双写 + 行锁排队，写 P99 会明显抬升甚至触发 lock wait。我不想拿生产高峰去赌。

已尝试的排查：① 在压测库（1/4 数据量，约 5000 万行）跑了 INPLACE 加索引，期间压写 TPS 不变，观察到写 P99 从 8ms 升到 22ms 左右，耗时约 3 小时；② 查过 performance_schema 的 events_waits，看到有 index 相关的 mutex 等待，但不确定是不是 INPLACE 引入的；③ 没敢直接在生产跑。

期望得到的答案形态：希望有人给一个「带数据」的权衡结论——① INPLACE 加索引期间写延迟的常见上涨区间，以及主要慢在哪个环节（索引树维护 / 双写 / 行锁）；② 2 亿行这个量级，INPLACE 大致耗时和磁盘/IO 压力，怎么估；③ 具体该盯哪几个监控指标（比如 Innodb_row_lock_waits、buffer pool 命中率、redo/undo 增速、磁盘 util）以及「涨到多少就该 ROLLBACK 放弃」的判停线；④ 有没有比 INPLACE 更稳的做法（比如影子表 + 双写迁移 / gh-ost），各自的落地成本。最好附命令或监控截图说明。