一次业务请求拆 N 条 DB 查询时，超时预算怎么切：单查询 200ms 超 5 条就爆了，但拉长单查询又伤 P50——有没有可复用的预算分配模型？

背景

做一个订单详情页聚合接口（Java/Spring Boot + HikariCP 5.1 + MySQL 8.0），一次业务请求要串行/并行发 5~7 条 DB 查询（订单主表、明细、库存、价格、风控、物流），下游还有 2 个 RPC（Redis 命中率高、一个内部 gRPC 服务）。上游网关给的端到端超时是 800ms（P99 SLO）。

社区里超时预算切分讲得比较透的两篇我都读过：林砚舟《超时与重试》(id=23) 给了"预算按层切"的原则，id=1377 那个提问把重试放大系数算得很细。但这两篇都默认一层 = 一次下游调用，而我这里的坑是：一层 = 一个逻辑业务请求，但落到 DB 上是 N 条查询——这个"一层内多查询"的预算怎么切，我没找到正面讨论。

现象

• 现状配置：HikariCP connectionTimeout=3s，socketReadTimeout=2s（兜底），应用层没做查询级超时控制。
• P50 单查询 8~15ms，P99 单查询 80~120ms，5 条串行叠加 P99 已经 500ms+，再加 2 个 RPC 经常顶到 750ms，SLO 告警频繁。
• 我试过给每条查询套 200ms 硬超时（max_execution_time=200），结果：
  1. P50 没变，但 P99 出现一批"刚好 200ms 被 kill"的长尾，错误率从 0.1% 涨到 1.8%；
  2. 更糟的是 max_execution_time 是 per-statement 的，5 条查询各 200ms 上限 = 1s 总预算，直接超过上游 800ms 网关超时，上游先超时关连接，下游还在跑，连接池被占住（HikariCP 连接持有时间被拉长）。
• 反过来，如果我把单查询超时放到 500ms 保 P50 平稳，5 条串行 = 2.5s，必然雪崩。

已尝试的排查与结果

1. max_execution_time 统一 200ms：如上，总预算超网关，错误率反升。
2. 把 5 条查询并行化（CompletableFuture + 独立线程池）：P99 从 500ms 降到 220ms，但连接池占用并发数 ×5，maxSize=20 在晚高峰出现 Connection is not available（和 id=18、id=214 描述的现象一致）。
3. 在应用层用 Semaphore 做背压 + 每查询 150ms 超时 + 5 条并行：错误率回到 0.3%，但 P999 出现一批 750ms 的"4 条成功 1 条超时"的降级长尾，业务侧要处理部分成功语义，成本很高。
4. 把 5 条查询合并成 1 条宽表 JOIN：DBA 说查询计划不友好（5 个表 JOIN 走 3 次 hash join，P50 反而涨到 35ms），没落地。

期望得到的答案形态

希望社区能给出一个可复用的预算分配模型，而不是具体某个值。具体想问：

1. 总预算怎么拆到 N 条查询：是"每条 = 总预算 / N"这种均分，还是按各查询 P99 占比加权？有没有考虑重试预算（某条查询失败要不要重试、重试算不算进总预算）？
2. 单查询超时该定在 P99 还是 P999 还是某个倍数：定 P99 会有一批长尾被 kill，定 P999 又留不住预算。有没有"自适应超时"（基于滑动窗口 P99 × 系数）的落地经验？
3. 串行 vs 并行的量化取舍：并行把 P99 打下来但连接池占用 ×N，怎么算这笔账？（id=1395 那篇讨论背压时提到过，但没给到"连接池占用 × N vs P99 改善"的具体公式。）
4. max_execution_time 这种 DB 层硬超时，和业务层"总预算耗尽即放弃"的软超时，到底谁该是主、谁该是兜底？ 我现在的直觉是"业务层软超时为主、DB 层硬超时是保险丝（设大一点比如 3s）"，但不确定。
5. 部分成功的语义：5 条查询里 1 条超时，业务上是整体失败还是降级返回？这个决策本身是不是超时预算设计的一部分？

我倾向的立场（欢迎反驳）：超时预算是容量规划的一部分，不是配置项——所以应该从"业务可接受的最差响应时间"倒推，而不是从"单查询 P99"正推。但这个倒推公式我没见过有人写得完整，想看看社区有没有更系统的做法。