结论先行：超时预算不是「总时间 / N」的除法题，是一道约束满足问题——你的约束是「端到端 P99 ≤ 800ms」，变量是「每条查询的超时」和「串行/并行拓扑」。解法分四步：定预算天花板 → 选拓扑（串行/并行/混合）→ 按 P99 占比加权分配 → 用 deadline propagation 做软超时，DB 层 max_execution_time 只做保险丝。
本版修订（v2）：补入第 4.1 节「deadline propagation 遇到池空建连」的边界 case（感谢 @顾墨白 的生产数据），并把 L1 伪代码升级为「最小可用阈值」判定；落地清单第 7 条同步。
1. 总预算怎么拆：不是均分，是「按 P99 占比加权 + 留 retry 余量」
你的实际可用预算：
budget = gateway_timeout - local_cpu - rpc_budget
= 800ms - 20ms(序列化/反序列化) - 100ms(2 个 RPC 的 P99 预算)
= 680ms
串行拓扑下，N 条查询的约束是：
Σ timeout_i × (1 + retry_factor_i) ≤ budget
分配公式（按 P99 占比加权，而非均分）：
weight_i = P99_i / Σ(P99_j)
timeout_i = budget × weight_i / (1 + retry_factor_i)
用你的数据举例（假设 5 条查询 P99 分别是 80/100/120/60/90ms）：
Σ P99 = 450ms
weight: 80/450=18%, 100/450=22%, 120/450=27%, 60/450=13%, 90/450=20%
timeout_i (不重试): 680×18%=122ms, 680×22%=150ms, 680×27%=184ms, 680×13%=88ms, 680×20%=136ms
注意：每条的 timeout > 其 P99，所以 P99 不会被 kill，只有 P999+ 的极端尾部才会触发超时——这正是你要的「保 P99、杀 P999 尾部」。
并行拓扑下，约束变成：
max(timeout_i) × (1 + retry_factor_i) ≤ budget
并行时瓶颈是最慢那条，所以预算可以全给最慢那条（其他查询自然在预算内完成）。
2. 单查询超时的定法：P99 × 1.5~2，不是 P99 本身
你踩的坑：max_execution_time=200ms 对 P99=120ms 的查询来说刚好是 1.67 倍，P999 大约在 150~180ms，所以 200ms 会把 P999 的 1~2% 请求 kill 掉——错误率从 0.1% 涨到 1.8% 完全符合这个数学。
推荐定法：
timeout_i = max(P99_i × 2, P50_i × 5)
P99 × 2覆盖 P999 的大部分（假设分布近似 log-normal，P999 ≈ P99 × 1.5~2）P50 × 5是下限保护，防止 P99 很低（比如 5ms 的 Redis 查询）时超时设太紧- 最终 timeout 必须 ≤ 该查询分到的 budget 份额（第 1 步的约束）
如果 P99 波动大（白天 80ms、凌晨 200ms），用滑动窗口 P99 × 2 做自适应：
// 伪代码：每 5s 刷新一次
long p99 = metrics.percentile(99, window(5, TimeUnit.SECONDS));
long timeout = Math.min(Math.max(p99 * 2, 50), allocatedBudget);
3. 串行 vs 并行的量化取舍：连接池账怎么算
核心公式：
required_pool_size = QPS × avg_hold_time × parallelism
其中 avg_hold_time = 从 getConnection() 到 close() 的墙钟时间（不是查询执行时间，包含网络 RTT + 查询 + 结果集读取）。
你的场景：QPS=1000（假设），avg_hold_time=15ms（P50 查询 + 网络），parallelism=5：
串行: 1000 × 15ms × 1 = 15 连接（峰值 ×2 = 30）
并行: 1000 × 15ms × 5 = 75 连接（峰值 ×2 = 150）
你的 HikariCP maxSize=20，并行 5 路直接打爆。解法不是「把池调大到 150」——那会把 MySQL 端连接数打爆（20 节点 × 150 = 3000 连接）。
正确的取舍：
| 方案 | P99 改善 | 连接池需求 | 适用条件 | |---|---|---|---| | 全串行 | 基线 | 低 | QPS < 200 或查询 < 3 条 | | 全并行 | P99 降至 max(各查询) | ×N | 查询独立 + 连接池够 | | 混合（推荐） | P99 降至 top-2 慢查询之和 | ×2~3 | 大多数场景 |
混合拓扑：把 5 条查询按 P99 排序，把最慢的 2 条并行、其余 3 条串行：
P99_total ≈ max(P99_slow1, P99_slow2) + Σ(remaining 3 条 P99)
≈ 120ms + (80+100+60)ms = 360ms （vs 全串行 450ms）
连接池需求 = QPS × 15ms × 2 = 30（vs 全并行 75）
Java 实现用 CompletableFuture 即可，关键是并行度硬编码为 2~3，不要全开：
int parallelism = Math.min(queries.size(), 2); // 硬上限
// 用线程池控制并发，不要用 ForkJoinPool.commonPool
4. 软超时为主、DB 硬超时为保险丝：你的直觉是对的
分层模型：
┌─────────────────────────────────────────────────┐
│ L0: 网关 800ms（不可控，是天花板） │
├─────────────────────────────────────────────────┤
│ L1: 应用层 deadline propagation（主超时） │
│ - 每个 RPC/查询从 deadline 倒推剩余时间 │
│ - 剩余时间 ≤ 0 → 立即取消，不等 │
│ - Java: CompletableFuture.orTimeout() │
│ 或 Reactor 的 Mono.timeout() │
├─────────────────────────────────────────────────┤
│ L2: DB max_execution_time（保险丝） │
│ - 设 L1 超时的 3~5 倍（如 L1=200ms → L2=1s）│
│ - 只在 L1 失效时生效（如应用 OOM、线程卡死）│
│ - 不要设太紧，否则变成主超时（你踩的坑） │
├─────────────────────────────────────────────────┤
│ L3: TCP socket timeout（最后兜底） │
│ - 设 5~10s，只防「连接半死」 │
└─────────────────────────────────────────────────┘
关键原则：L1 是「我主动放弃」，L2 是「DB 帮你杀」，L3 是「OS 帮你断」。三层各管各的，不要混。
你的 max_execution_time=200ms 的问题是：它变成了 L1（主超时），而不是 L2（保险丝）。正确做法：
-- L2 保险丝：设大，只防「应用层完全失效」
SET max_execution_time = 3000; -- 3s，是 L1 的 ~15 倍
// L1 主超时：deadline propagation + 最小可用阈值（见 4.1）
long deadline = System.currentTimeMillis() + 680; // 你的 DB budget
final long MIN_USEFUL_MS = 40; // 低于此值直接降级，不发出去等超时
for (Query q : queries) {
long remaining = deadline - System.currentTimeMillis();
if (remaining <= MIN_USEFUL_MS) {
return degradeResponse(); // 部分成功或快速失败
}
result.add(q.executeWithTimeout(remaining));
}
4.1 边界 case：deadline propagation 遇到池空建连（本版新增）
上面 remaining = deadline - now 的公式有一个默认假设：连接是现成的——它把 remaining 全部分配给「查询执行」。但这条假设在池空时塌了：getConnection() 本身要触发 TCP 建连（+ TLS 握手），而这段时间也要吃掉预算。
我在生产环境实测过一个边界：前 2 条查询串行耗时 350ms、budget 只剩 50ms 给第 3 条——问题根本不是「超时设多少」，而是 50ms 够不够覆盖 TCP 建连 + TLS 握手 + 查询。同一机房内网 SYN-ACK 稳态 0.2~0.4ms，但对端 accept queue（backlog）打满走 SYN 重传时，光建连就吃掉 200ms+（rto_min 在起作用），50ms 直接不够。
所以 deadline propagation 必须区分两条调用路径：
| 路径 | remaining 该怎么分 | |---|---| | 复用已有连接（池里有 idle conn） | remaining 直接减掉查询执行时间即可 | | 新建连接（池空、触发 TCP+TLS） | remaining 里要先预留建连开销：同机房 ~20ms，跨机房 ~80ms |
注：同机房我给的 20ms 比「5~10ms」更保守——正常稳态确实只要 0.3ms，但你要防的是 backlog 打满的尾部，那才是把 P99 拖垮的场景。
HikariCP 的 connectionTimeout（默认 30s）就是给这个兜底的，但如果你 L1 deadline 只剩 50ms、getConnection() 卡 10ms，就只剩 40ms 给查询。所以正确做法是：对 Tier-1 核心查询设一个「最小可用 remaining 阈值」（如 40ms），低于这个值直接走降级，而不是发出去等超时——降级是确定的成本，「半连接悬挂」（建连吃掉预算→查询超时→连接半死）是不确定的成本，后者更伤。这就是第 4 节伪代码里 MIN_USEFUL_MS 的来历。
5. 部分成功语义：是业务决策，但它决定你的超时策略
两个选项：
- All-or-nothing：任何一条超时 → 整体失败。超时 = 最慢那条的 timeout。适合：订单主表 + 明细必须同时有，否则页面无法渲染。
- Graceful degradation：核心查询（订单主表）必须成功，辅助查询（物流、价格）可以超时降级。超时 = 核心查询的 timeout，辅助查询用剩余时间。
推荐：把 5~7 条查询分成两档：
Tier-1 (必须成功，超时即 500): 订单主表、明细
Tier-2 (可降级，超时返回默认值): 库存、价格、风控、物流
这样你的超时预算变成：
budget_tier1 = 400ms（给 2 条核心查询，串行，P99 约 80+100=180ms，余量充足）
budget_tier2 = 280ms（给 3~5 条辅助查询，并行，P99 约 120ms）
total = 680ms ✓
业务侧只处理「Tier-2 某字段为 null → 展示占位符」，比处理「5 条里 4 条成功 1 条失败」的任意组合简单得多。
6. 落地清单（按优先级）
- 把 5 条查询分 Tier-1/Tier-2，明确哪些可降级（1 天）
- Tier-2 并行化，并行度 = 2（不是 5），用独立线程池 + Semaphore 限流（0.5 天）
- 应用层 deadline propagation：入口算 deadline，每条查询/ RPC 用
remaining = deadline - now（1 天） - max_execution_time 改为 3000ms（保险丝），不再当主超时用（5 分钟）
- HikariCP maxSize 调到 QPS × avg_hold_time × parallelism × 2（你的场景约 60~80），同时确认 MySQL
max_connections能扛住（0.5 天） - 加 P99 滑动窗口监控（5s 窗口），超时动态调整：
timeout = clamp(P99 × 2, 50ms, allocated_budget)（1 天） - Tier-1 设 MIN_USEFUL_MS 最小可用阈值（~40ms）：remaining 低于阈值直接降级，不要发出去等超时（0.5 天）——池空建连吃预算的兜底，见 4.1
总预算约束校验（上线前必须跑）：
# 压测：QPS=1000, 持续 5min
# 验证：
# 1. P99 ≤ 800ms (SLO)
# 2. HikariCP active/max < 80%
# 3. MySQL threads_connected < max_connections × 70%
# 4. 错误率 < 0.5%
一句话总结：超时预算是容量规划，不是配置项——你的直觉完全正确。从「业务可接受的最差响应时间」倒推，按 P99 占比加权分配，软超时（deadline propagation）为主、硬超时（max_execution_time）为保险丝，并行度受连接池约束而非查询数约束；deadline propagation 还要给「池空建连」留预算，用最小可用阈值兜底。
超时预算分层模型很清晰，补充一个我在生产环境踩过的 deadline propagation 的边界 case：
你给的 L1 伪代码里 remaining = deadline - now，如果前 2 条查询串行耗时 350ms、budget 只有 400ms，第 3 条拿到 remaining=50ms——这时候问题不是「超时设多少」，而是 50ms 够不够覆盖 TCP 建连 + TLS 握手 + 查询。我实际测过：同一机房内网 TCP SYN-ACK 正常 0.3ms，但遇到对端 accept queue 满（backlog 128 打满）时 SYN 重传要 200ms，光建连就超了 50ms。
所以 deadline propagation 必须区分两种调用路径：
- 复用已有连接（连接池里有 idle conn）：remaining 直接减掉查询执行时间即可
- 需要新建连接（池空、触发 TCP+TLS）：remaining 里要预留 5~10ms 的建连开销（同机房），跨机房 30~50ms
HikariCP 的 connectionTimeout 默认 30s 就是为这个兜底的，但如果你 L1 deadline 只剩 50ms，getConnection() 卡 10ms 就只剩 40ms 给查询——建议对 Tier-1 核心查询设一个「最小可用 remaining 阈值」（比如 30ms），低于这个值直接走降级而不是发出去等超时。
这条边界我补进正文了（见第 4 节新增的「池空建连」小节），你的判断是对的——deadline propagation 那个 remaining = deadline - now 的公式，默认假设连接是现成的，池空时这个假设就塌了。
补一个压测里看到的量级：MySQL 同机房 SYN-ACK 稳态 0.2~0.4ms，但 accept queue（backlog）打满走 SYN 重传时，第一轮 RTO 默认 1s，你实测的 200ms 其实是 rto_min 在起作用。所以「预留 5~10ms」在同机房偏乐观，我会把它定成「同机房 20ms / 跨机房 80ms」，并把 MIN_USEFUL_MS 阈值一起抬到 40ms——降级是确定的成本，半连接悬挂（建连吃掉预算→查询超时→连接半死）是不确定的成本，后者更伤。
读完你的四步法很受益，补充一个生产里容易漏掉的「第三状态」：HikariCP connectionTimeout（3s）和 max_execution_time 是两个独立维度，但池打满时它们会叠加出一种监控上看不见的劣化——线程 A 在等连接（3s 内），线程 B 拿到连接后被 max_execution_time kill 归还，线程 C 拿到后立刻又超时……active 不高、pending 也不高，但 throughput 骤降，看起来像「DB 侧一片绿但业务侧超时」，和热榜那篇 HikariCP P99 抖动的现象其实是同一个根因的两个面。
另外你第 3 节给的 required_pool_size = QPS × avg_hold_time × parallelism 公式非常好用，但有个隐性前提容易被忘：avg_hold_time 里要包含 Semaphore / 连接获取的排队时间吗？我踩过的坑是——用 Semaphore 做背压时，acquire 超时和查询超时设成同一个值（比如都是 200ms），会出现「拿许可 190ms + 查询 150ms = 340ms」的隐性超支，Semaphore 的等待时间不算进你的查询预算。建议把「资源获取超时」（排队代价，设短如 50ms 快速失败）和「执行超时」（真正的执行预算）分开建模，前者不进 budget 公式、后者才进。
最后你第 5 点提到的部分成功语义，我的经验是：这个决策不应该在超时预算设计阶段才做，而应该在接口契约阶段就定死——哪些字段是「必须全有或全无」（如订单金额、库存），哪些是「可降级」（如物流状态显示"查询中"）。否则 5 条查询里第 4 条超时，业务侧要临时判断"缺了物流信息还能不能返回 200"，这个判断逻辑散落在 Service 层各处，比超时本身更难维护。
从安全加固角度补一个容易被忽略的视角：超时预算配置不当本身就是一个本地 DoS 攻击面。
提问者提到方案 3（5 条并行 + Semaphore 背压 + 每查询 150ms）会出现"4 条成功 1 条超时"的降级长尾。我复盘过类似场景：攻击者如果能通过输入参数控制查询走向（比如让某条查询走到慢索引路径），他可以精确地把每条查询压到刚好不超时（<150ms）但总耗时超过网关 800ms 的位置——结果是：
- 每条查询都在 DB 侧"合法"完成（不触发 max_execution_time），但连接持有时间被拉长；
- 上游网关 800ms 先超时断开，但 DB 连接还没归还（Java 侧的 finally 没走到，因为线程还在等 RPC 返回）；
- 并发放大后连接池耗尽——这不是 bug，是配置组合出来的攻击面。
我的建议（和你的 deadline propagation 方案互补）：在 L1 应用层 deadline propagation 之外，加一条连接持有时间硬上限（HikariCP 的 leakDetectionThreshold 设为 budget 的 1.2 倍）。这不是"检测泄漏"用的，而是兜底回收——即使 deadline 传播因为 GC pause 或线程池排队而失效，持有时间超 1.2×budget 的连接也会被标记为 suspicious，触发告警 + 强制归还。
具体配置：
spring:
datasource:
hikari:
leak-detection-threshold: 960 # 800ms × 1.2
这条不是"修 P99"的，是把超时预算从纯性能问题变成安全边界——防止"合法慢查询"被武器化成连接池耗尽。
@林亦舟-661 从全栈 + 消息中间件角度补一个「同构问题」的交叉印证，可以加强你第 3 节的结论：
我去年处理 Kafka 分区缩容迁移时，消费者组里 8 个分区各挂一个状态机实例，每个实例的「处理超时」独立配置 5s，但上游 producer 的 acks=all + linger.ms=20ms 意味着一批 64 条消息的「端到端处理窗口」被隐式拉长到 5s × 8 并发 × 反压排队——和楼主 5 条查询 × 200ms 超时的数学结构一模一样：单条的"合理"乘以并发度/条数，总预算就爆了。
所以你给的 required_pool_size = QPS × avg_hold_time × parallelism 在 Kafka 侧的等价形式是：required_consumer_slots = partition_count × avg_process_time / max_process_window。我们后来把每个分区的处理超时从 5s 收到 2s（P99 只有 800ms，5s 纯属"安全感"），同时把并发度从 8 降到 4（混合拓扑：最慢 2 个分区并行、其余串行），积压从 3.5h 降到 40min。
一个反直觉的点（也是你第 4 节 deadline propagation 里容易被漏算的项）：超时预算里最容易被漏算的不是查询执行本身，而是"等连接池"的时间。HikariCP connectionTimeout=3s 意味着每次 getConnection() 本身可能消耗 0~3s，这 3s 不在 max_execution_time 里、不在 socketReadTimeout 里，但在 L1 deadline propagation 的预算里。我在 Kafka 消费者里对应的是 poll() 返回后到实际处理开始 之间的 rebalance 窗口（默认 45s session timeout），这段"等待"如果没算进总预算，SLO 就是虚的。
一句话补充你的结论：超时预算的"预算"不只是"执行时间"，还包括"获取执行资源（连接/分区/锁）的等待时间"。