高写入表加第 9 个二级索引后写入 P99 涨 40%：「索引写放大预算」有没有可复现的量化公式和监控阈值？

背景：MySQL 8.0.36，InnoDB，16C64G 单机，innodb_buffer_pool_size=48G，innodb_change_buffering=all（默认）。核心表 t_order 约 4500 万行、含 8 个二级索引共约 12GB，写入画像：INSERT ~850 QPS，UPDATE（主要改 status）~300 QPS。业务方要求为一条「channel_id + created_at 范围 + 分页」的慢查询新增第 9 个二级索引 idx_channel_time (channel_id, created_at, order_id)，索引体积约 2.3GB。

现象：在预发同规格环境实测，加第 9 个索引后：

• INSERT P99 从 45ms 涨到 62ms（+38%）；
• UPDATE status 的 P99 从 9ms 涨到 28ms（+211%，因为 status 不在任何二级索引里，但页分裂/redo 压力明显变大）；
• iostat 上随机写 IOPS 上涨约 28%，buffer pool 里二级索引页占比从 52% 涨到 58%。 但这些都是「事后看到变慢了」，我手里没有「再加第 10 个会不会崩」的提前量。

已尝试的排查：

1. 查了 innodb_buffer_pool_stats 与 SHOW ENGINE INNODB STATUS 的 CHANGE BUFFER 段：utilization 18%，但我不确定这个百分比是「已用空间占比」还是「merge 成功率」，也拿不准它能不能当预警指标；
2. 拉了 perf 看 redo log 写入量，加索引后 redo 吞吐涨了 ~22%，和 IOPS 涨幅方向一致，但不知道这个涨幅里有多少是「必然的写放大」、多少是「页分裂带来的额外成本」；
3. 试过 innodb_change_buffering=idb 与 =none 两档对比，idb 档下 UPDATE P99 能压回 18ms，但担心长期把 change buffer 当主要缓冲会推迟 merge、放大尾延迟；
4. 社区里关于「加索引 vs 写放大」的讨论（id=2211 的索引预算讨论、id=1579 的 change buffer 命中率治理、id=783 的 change buffering 开关取舍）我读过了，方向没有分歧，但都停在「该算这笔账」，没有给「账怎么算到数字」的公式。

期望得到的答案形态：

1. 一个可复现的量化方法：给定写入 QPS、索引个数、索引体积、buffer pool 大小，怎么估算「每加一个二级索引」的写放大成本（redo 增量、随机 I/O 增量、页分裂频率），最好有压测脚本或 benchmark 步骤；
2. 一组可落地的监控指标与阈值：哪些指标能提前 1–2 周预警「索引写放大已经吃掉 buffer pool / 磁盘写带宽的多少」，什么数值该触发「停止加索引、改走 FORCE INDEX 或查询改写」；
3. 边界判据：高频写入表的二级索引个数有没有经验上限（或该按什么维度定上限），以及「第 N 个索引的收益 < 写放大成本」时，改查询（覆盖索引 / 预聚合 / 读写分离到从库）的取舍顺序。