加索引前如何事前评估「优化器对同表其他查询的重规划风险」：有没有可复现的 pre-flight checklist 或半自动方法？

【背景】 MySQL 8.0.32 / InnoDB，单主 32C128G，innodb_buffer_pool_size=96G。核心表 t_settlement 约 1.2 亿行，当前含 PK + 4 个二级索引（idx_merchant_time、idx_batch_no、idx_status_merchant、idx_created_at）。日常写入 INSERT 为主约 800 TPS，少量 UPDATE status。

当前要治理的慢 SQL：

SELECT id, amount, status FROM t_settlement
WHERE merchant_id = ? AND status IN ('PENDING','PROCESSING')
ORDER BY created_at DESC LIMIT 50;

EXPLAIN 显示 type=ALL、rows≈1.2亿，P99 稳定在 1.4s（日常 200 QPS 的点查）。我准备加联合索引 idx_merchant_status_created (merchant_id, status, created_at DESC)，预期把这条 P99 压到 5ms 以内。

【现象 / 我担心的点】 这条表上还有另外 6 条高频查询（日均合计 3000+ QPS），其中 2 条 WHERE 条件只带 merchant_id（不带 status），1 条是 WHERE status = 'PENDING' AND created_at > ?（不带 merchant_id）。我担心加了新索引后，优化器可能：

1. 把那 2 条只有 merchant_id 的查询从原来的 idx_merchant_time 切到新索引（前缀匹配 merchant_id 后走 status 的 range + created_at 排序），如果 status 选择性差（3 个值），回表成本可能反而更高；
2. 把第 3 条 status 查询从全表扫（当前 P99 420ms，业务可接受）切到新索引（status 在前缀第二位，无法利用），导致退化为全索引扫描。

【已尝试的排查与结果】

• 对 6 条高频 SQL 逐一 EXPLAIN（加索引前），确认当前各自走的索引和 type；
• 在测试库（数据量 1/10，1200 万行）加了该索引后重跑 EXPLAIN：第 1 类查询确实被优化器切到了新索引（type=range，rows 估算从 8000 降到 2600），但测试库数据分布与生产不完全一致，我不敢拿这个结果直接下结论；
• 翻了 performance_schema 的 table_io_waits_summary_by_index_usage，确认当前 4 个索引的读/写计数分布，新索引加入后这些计数会不会漂移我没有把握；
• 看了社区里陈墨白-592 的讨论帖（id=1500）提到"优化器误选"风险，以及陈寒山-172 的文章（id=208）讲统计信息漂移导致执行计划突变——但这两篇都偏「事后发现」，我想知道的是「事前怎么系统性排查」。

【期望得到的答案形态】

1. 你们在生产环境加索引前，有没有一套可复现的 pre-flight 流程（比如：拉出同表所有 SQL → 在 staging 跑 EXPLAIN 对比 → 用 optimizer_trace 确认候选计划 → 灰度观察 N 分钟）？具体步骤和工具链是什么？
2. 有没有半自动化的方法（pt-online-schema-change 的 --test-table-name、或自研脚本 + information_schema.STATISTICS + performance_schema 的组合）能在 DDL 执行前给出「哪些现有查询的计划会发生变化」的 diff 报告？
3. 如果你们没有事前流程、都是上线后观察 P99 兜底——你们观察窗口一般多长、看哪些指标（P99、QPS、buffer pool 命中率、lock wait）、阈值怎么定才算"安全"？

我倾向于不要"加完观察一周再说"这种兜底方案，1.2 亿行 + 800 TPS 写入，一旦新索引导致某条高频 SQL 从 idx 切到全表扫，影响面是秒级的。想听听大家更体系化的做法。