慢日志里 20 条慢 SQL 都该修、人手只有 1 周：有没有一套「影响面 × 频率 × 改善空间 ÷ 成本」的可复现打分排序，先修哪条不靠拍脑袋？

【背景】 我在一家中厂做大数据平台，慢查询治理是日常。上周一次例行巡检，从一张 4000 万行的 t_trade_order 库拉了 7 天慢日志，去重后得到 23 条 distinct 的慢 SQL（阈值 1s），平均每条 P99 在 1.2s～9s 之间。团队这周只有 1 个 DBA + 1 个开发，只能修 3～4 条。于是要问一句：先修哪 3 条？

【现象 / 卡点】

• 按「最慢的那条优先」排序：那条 9s 的其实是 T+1 批处理跑批 SQL，一天只跑 1 次，用户根本感知不到，修它收益极低；
• 按「出现频率最高的优先」排序：那条 1.2s、每天 3000 次的客服后台查询，P99 其实已经被缓存兜住，用户侧 P99 才 180ms，修它改善空间几乎为零；
• 真正影响用户的是中间那几条：P99 3～5s、每天几百次、且是支付/下单主链路、目前没有缓存兜底——但这恰恰不是「最慢」也不是「最高频」。

所以我的卡点是：有没有一套可复现的打分/排序方法，把「影响面（是否主链路、是否被缓存兜住、QPS）× 出现频率 × 改善空间（P99 还有多少可降）÷ 治理成本（加索引 vs 改 SQL vs 改架构，回滚难度）」量化成一个分数，让「先修哪条」从拍脑袋变成算得出来的事？

【已尝试的排查与结果】

1. 直接按 time 降序 → 选出了跑批 SQL，错了（收益低）；
2. 按 count 降序 → 选出了被缓存兜住的客服查询，错了（改善空间小）；
3. 手动给每条 SQL 标「主链路/非主链路」「有缓存/无缓存」，再脑内加权 → 这次选对了，但没法向别的团队复现，换一个 DBA 又拍不出一样的结论。

我隐约觉得应该有个类似 score = (链路权重 × QPS × 可降 P99 空间) / 成本档 的公式，但具体权重怎么定、各档怎么划分、有没有人真在线上这么排过序，我没有可复现的参考。

【期望得到的答案形态】

• 最好给一套可落地的打分公式或 checklist：每个因子怎么取数（慢日志 / performance_schema / 应用侧 QPS）、权重或分档怎么定、有没有真实案例「按这套排序修了前 3 条后 P99 降了多少」；
• 或者给一个反例 + 边界：哪些场景下「频率 × 影响面」排序会失效（比如长尾低频但每次都是资损的 SQL），你们团队是怎么兜底的；
• 加分项：有没有半自动脚本/SQL，直接从 sys.statements_with_runtimes_in_95th_percentile 或慢日志吐出这个排序表。

我认同热榜里关于「优化 ROI」的讨论方向，也认同慢查询治理要分「定位 → 判断 → 治理」的顺序；但「治理这一步该先动哪一条」的量化排序，我还没找到共识做法，想向各位要一套能抄的路径。