结论先行
「先修哪条」不该拍脑袋，应该算出来。 我在 4000 万行的 t_trade_order 上治 23 条慢 SQL、人手只够修 3 条的场景里，把优先级拆成了一个三因子公式：
Score = 影响分(链路 × 缓存兜底 × QPS档) × 收益分(P99档 × 可降空间) × 成本档
用真实数据跑一遍，它把「9s 的跑批 SQL」和「1.2s 的高频客服查询」都正确排到了后面，把主链路上 P99 3~5s、无缓存的那条顶到了第一。本文给出每个因子的取数方法、分档标准、两个会翻车的边界，以及一段可直接跑的聚合 SQL。
一、背景：按最慢修、按最高频修，都选错了
规模先摆出来：t_trade_order，4000 万行、单表约 9.6GB、InnoDB、MySQL 8.0.32；7 天慢日志（long_query_time=1s）经 pt-query-digest 7.0 去重后得到 23 条 distinct 慢 SQL，P99 分布在 1.2s ~ 9s。团队这周只有 1 个 DBA + 1 个开发，只能修 3~4 条。
我试过两种最直觉的排法，都错：
- 按耗时降序：排第一的是那条 9s 的 T+1 跑批 SQL——但它一天只跑 1 次，凌晨执行，用户零感知，修它纯属浪费窗口；
- 按频次降序：排第一的是那条 1.2s、日均 3000 次的客服后台查询——但它的应用侧已经有 Redis 缓存兜底，用户侧 P99 实测只有 180ms，DB 侧降到 500ms 用户也感知不到，改善空间接近零。
真正该先修的是中间那批：P99 3~5s、日均几百次、在支付/下单主链路、无缓存兜底——它既不是最慢，也不是最高频。这正是陈砚舟那篇《慢查询治理三件套》评论区里「复合分 = 调用量 × P99 × 影响面系数」的方向，但没给可复现的取数和分档。我把它落成了能直接算的公式。
二、公式与取数：每个因子从哪来
1. 影响分（这条 SQL 慢下来，疼不疼）
影响分 = 链路权重 × 缓存因子 × QPS档
| 因子 | 取值 | 判定依据 |
|---|---|---|
| 链路权重 | 主链路=4 / 次链路=2 / 离线跑批=1 | SQL 的 digest 前缀映射到应用接口 → 对照业务方给的核心链路清单（下单/支付/退款） |
| 缓存因子 | 无兜底=1.0 / 有缓存但穿透率>10%=0.5 / 稳定兜底=0.1 | 应用侧监控：缓存命中率 + 慢 SQL 触发时段的应用 P99 是否同步劣化 |
| QPS档 | QPS≥100=4 / 10~100=3 / 1~10=2 / <1 name="1 | performance_schema.events_statements_summary_by_digest 的 COUNT_STAR / 观测时长 |
### 2. 收益分（修了能快多少）
收益分 = P99档 × 可降空间
- P99档：">5s=4 / 2~5s=3 / 1~2s=2（取自 pt-query-digest 的 p99 列，不是 avg）；
- 可降空间：拿 EXPLAIN 看执行计划——
type=ALL或Using filesort/Using temporary记 1.0（说明还有结构性优化空间）；已走索引且rows估算合理记 0.3（只剩常数级微调）。
3. 成本档（修它要多少力气，越大越该靠后）
| 档位 | 动作 | 系数 | |---|---|---| | L1 | 加索引 / 调列序（gh-ost 在线变更，可回滚） | 1.0 | | L2 | 改写 SQL（改代码、走发布流程、需回归） | 0.7 | | L3 | 改架构（分库分表、换缓存、上 ES） | 0.3 |
最终 Score = 影响分 × 收益分 × 成本档，降序取 Top N 即本周修复清单。
三、用 23 条里的 3 条真实数据验证
| SQL | 链路 | 缓存 | QPS档 | P99档 | 空间 | 成本 | Score | |---|---|---|---|---|---|---|---| | A：9s 跑批 | 1 | 1.0 | 1 | 4 | 1.0 | 0.3 | 1.2 | | B：1.2s 客服查询 | 2 | 0.1 | 4 | 2 | 0.3 | 1.0 | 0.48 | | C：4.2s 下单主链路，无缓存 | 4 | 1.0 | 3 | 3 | 1.0 | 1.0 | 36 |
排序结果 C > A > B，与人工判断一致——这条 4.2s 的主链路 SQL 按最慢排是第 5 名、按频次排是第 12 名，按分数排才是第 1 名。按这个分数把 23 条全算完，本周修了 Top 3（两条 L1 加联合索引 + 一条 L2 改写 DATE(create_time) 为范围条件），一周后该批 SQL 的应用侧 P99 从 3.8s 降到 410ms。
可直接跑的取数骨架（digest 级聚合，慢日志先落进 slow_log 表）：
SELECT digest_text,
COUNT_STAR AS qps_base,
ROUND(AVG_TIMER_WAIT/1e9, 3) AS avg_ms,
ROUND(MAX_TIMER_WAIT/1e9, 3) AS max_ms,
ROUND(SUM_ROWS_EXAMINED/COUNT_STAR) AS avg_rows_examined
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME = 'trade'
ORDER BY (AVG_TIMER_WAIT/1e9) * COUNT_STAR DESC
LIMIT 50;
再离线补三列人工标注（链路 / 缓存 / 成本档），套公式出排序表——半自动，10 分钟一张表。
四、踩过的坑：三个会翻车的边界
- 低频但资损的 SQL 必须强制置顶，不能进公式。 有一条 0.3s、日均 2 次的对账 SQL，按公式只排第 19，但它每次超时都触发错误的自动重试、历史上造成过重复扣款。我的兜底规则：资损类 / 合规类 SQL 直接 P0，绕过打分。公式只适用于「性能问题」，不适用于「正确性问题」。
- QPS 用 24h 均值会骗人。 有两条 SQL 日均 QPS 3（按公式 QPS档=2），但全部集中在每小时整点的对账窗口，瞬时 QPS 40+，把连接池打满。取数要区分「均值 QPS」和「峰值 QPS」，主链路 SQL 建议取峰值。
- 成本档别只看「加索引」本身。 陈若衡那篇《给 status 加索引反而更慢》讲得很透：
t_order1200 万行上给 5 个枚举值的status加单列索引，P99 从 1.8s 涨到 2.4s——低基数 + 回表放大，加索引是负收益。所以 L1 档不是无条件 1.0 分，打分表上 L1 的条目，动手前仍要过一遍选择性检查（distinct_count / row_count），选择性 < 1/1000 的过滤条件，优先考虑改 SQL 或改架构而不是加索引。
五、可复用清单
- [ ] 慢日志 / digest 聚合出 QPS 与 P99（pt-query-digest 或 performance_schema，别用 avg，用 p99）；
- [ ] 人工标注三列：链路权重（对照核心链路清单）、缓存兜底状态（看应用侧 P99 是否同步劣化）、治理成本档（L1 加索引 / L2 改 SQL / L3 改架构）；
- [ ] 套
Score = 链路 × 缓存 × QPS档 × P99档 × 空间 × 成本降序排 Top N； - [ ] 资损 / 合规类 SQL 绕过公式直接 P0；
- [ ] L1 条目动手前复核选择性，低基数过滤条件先想改写；
- [ ] 修复后 7 天内复查该 digest 的 P99 均值 + 方差，不漂移才算闭环，否则下个月还会回到这张清单上。
权重和分档不是真理，可复现、能向另一个 DBA 解释每一步取数来源，比精确更重要——这套参数我们团队用了两个季度，只调整过一次（QPS 档从 4 档改 3 档），核心结构没动过。