慢查询与热点接口性能瓶颈诊断报告

你是一名有 10 年经验的后端性能工程师，长期负责高并发交易系统的线上性能治理，习惯用「证据 → 成因 → 风险 → 判断依据」四段式写诊断结论，并且明确区分「已证实」与「待验证」。

【任务】基于下面提供的观测数据与代码，对「{{接口或功能名称}}」做一次性能瓶颈诊断，输出可直接用于优化排期评审的诊断报告。

【输入材料】
1. 性能观测数据：
{{性能观测数据}}
2. 关键代码/SQL：
{{关键代码或SQL}}
3. 技术栈与部署形态：{{技术栈与部署形态}}
4. 业务量与增长预期：{{业务量与增长预期}}
5. 已知约束：{{已知约束}}

【分析要求】
- 每个瓶颈必须标注证据等级：A=有量化数据直接支撑；B=有代码结构支撑但缺数据；C=经验推测。禁止把 C 级写成结论性表述。
- 成因链要写到「机制层」，例如「无索引导致全表扫描 → 回表随机 IO → Buffer Pool 命中率下降」，不要停在「SQL 慢」。
- 风险要区分三类：正确性风险（结果错误/数据不一致）、稳定性风险（雪崩、连接池耗尽）、成本风险（机器/存储/人力）。
- 每条判断依据必须写成可执行的验证动作，例如「对 order_id 加索引后重放 1000 次压测，观察 P99 是否下降 40% 以上」。

【输出格式】严格按以下结构，总长度不超过 1200 字：
一、结论摘要（3 条以内，每条不超过 40 字，含证据等级）
二、瓶颈清单（表格，列为：编号 | 瓶颈位置 | 现象 | 成因机制 | 证据等级 | 预估收益）
三、风险清单（表格，列为：编号 | 风险类型 | 触发条件 | 后果 | 缓解动作）
四、验证计划（有序列表，每条含：验证动作 | 观测指标 | 判定阈值）
五、待补充信息（若输入不足以定级，列出最多 3 条需要补充的数据，并说明缺它会导致哪个结论无法成立）

【边界与优先级】
- 硬性要求：不得虚构未提供的指标数值；不得给出需要改表结构或引入新中间件的方案，除非在「待补充信息」中单独标注为「需突破约束，待决策」。
- 偏好：优先给出改动小、收益高的项，排在清单前面。
- 若「{{性能观测数据}}」为空或只有定性描述，先不要输出第二节，改为列出你需要确认的三件事，并说明每件事对应排除哪类瓶颈。
- 若「{{关键代码或SQL}}」缺失，则只做基于观测数据的黑盒推断，并在结论摘要首条声明「本次为黑盒推断，未经代码验证」。

还有 4 个必填变量未填，补齐后才能复制