低频慢 SQL（300~500 次/天）治理：加索引是「7×24 持续付」，改 SQL 有 2 周排期，这笔成本收益时间尺度不对称的账怎么算？

【背景】 我是 DBA，3 年经验，主要做数据库设计与慢查询治理。主库 MySQL 8.0.32（社区版，InnoDB，单主 16C64G，innodb_buffer_pool_size=32G），核心业务表 t_report_src 约 1200 万行、当前已有 4 个二级索引（含 idx_tenant_time (tenant_id, created_at)），写入以 INSERT 为主，日常 QPS 300~500、峰值约 800。

【现象】 库里唯一还慢的是一条低频报表 SQL，业务方报表工具里写死：

SELECT tenant_id, status, amount, created_at
FROM t_report_src
WHERE created_at BETWEEN ? AND ?
ORDER BY created_at DESC
LIMIT 20;

EXPLAIN 确认 type=ALL、key=NULL、rows≈1200万，确实是全表扫，P99 稳定在 3~5s。它的特点是低频：白天集中，全天约 300~500 次，夜间几乎为 0。

【已尝试的排查与结果】

1. EXPLAIN 已确认全表扫（如上），不是统计信息漂移、也不是锁等待，慢就慢在扫描量本身；
2. 现有的 idx_tenant_time (tenant_id, created_at) 命不中——这条报表 SQL 的口径是跨租户汇总，WHERE 里没有 tenant_id，所以用不上已有索引；
3. 找业务方改 SQL（加 tenant_id 收窄 / 改走已有索引），对方明确「报表口径必须跨租户，不能加 tenant_id」，且即便硬改也要走他们排期，预计 2 周；
4. 加索引方案：加一个 idx_created_status (created_at, status) 之类的索引可覆盖查询，但这是该表的第 5 个二级索引。

【我真正卡住的点】 这是一笔成本收益时间尺度不对称的账，我一时没法把两个量纲放同一把尺子比：

• 加索引：当天能上，但写入放大是 7×24 持续付（每个 INSERT/UPDATE 多维护 1 个二级索引 + 多写 redo + 潜在页分裂），而且索引再多一个，优化器在其它 SQL 上误选的概率、长期维护成本都会上升（1500 号讨论里提过「加索引不是零成本动作」，但没给量化判据）；
• 改 SQL：业务方 2 周排期，这期间这条 SQL 继续 3~5s；
• 而收益是每天 300~500 次点状，成本是7×24 持续付——一个点一个面，两个时间尺度对不齐，我怕拍脑袋。

我知道「补索引后写 QPS 掉多少」这种事后算账社区已经有人量化过（885 号提问），我想问的是事前决策这笔账：

【期望得到的答案形态】

1. 一个可复算的判据/公式：怎么把「加索引的持续写入放大成本」和「等 2 周改 SQL 的机会成本（期间每天 300~500 次 × 3~5s 的业务损失）」放到同一把尺子上比？写入放大到底怎么估算（按 写入 QPS × 每行多写的索引页数 × redo 量 之类的口径，有没有更准的）；
2. 低频慢 SQL（300~500 次/天）治理，你们团队的实际默认动作是什么——容忍 / 加索引 / 改 SQL / 上缓存 / 走从库？背后的量化依据是什么（比如「低于 X 次/天就不值得加索引」这种阈值，你们内部是怎么定的）；
3. 有没有不破坏主表写入、又能把这条低频 SQL 打下来的第三方案，以及各自落地成本：比如走只读从库专门跑这条、加一个「只覆盖这条查询的索引但只建在从库上」、或做物化/汇总表？你们实际踩过哪种、效果如何？

（引用说明：885 号已量化「补索引后写入放大」的事后账、1500 号讨论过「加索引是隐性成本」，本文聚焦的是事前、且收益低频 vs 成本持续的时间尺度不对称这块还没人给判据的角落。）