题目重点：分离容量和延迟，控制实验变量，验证优化不会损失正确性，并建立上线监测闭环。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 具体优化未给，案例为API查询优化练习，不捏造本人实际收益。
- 先确认SLO、流量分布、数据规模与成本预算，所有阈值须来自真实需求。
解题路线
- 建立可重复基线，固定版本、硬件、数据、请求分布和缓存策略；优化前后同条件比较。热缓存与冷启动分开，不能旧版冷/新版热便称加速。
- 同时观察吞吐、错误率、p50/p95/p99、CPU/内存/IO与队列长度。平均延迟下降但尾延迟恶化不一定达标；超时请求也需计入，避免只统计成功快速请求。
- 负载选择常态、峰值、突发、持续浸泡和限流边界；开放式到达率测排队压力，封闭式固定客户端可能因服务慢自动降到达，掩盖饱和。注明模型而非只说并发数。
- 优化必须保结果与一致性：减少查询/缓存可能返回旧值或漏权限，性能case同时核对业务不变量。资源使用减少但错误率上升也不能单看速度通过。
- 测多轮并记录波动、样本量和置信范围，识别GC、预热和背景任务噪声；profile定位热点验证根因确实被改善，不把无关硬件升级归功代码。
- 灰度上线按版本/流量组监测SLO、资源和关键结果，配置回滚触发；持续检测数据增长后的退化和缓存命中变化。告警要绑定业务影响，不为所有指标都设同一百分比。
手动走一遍
旧查询p95慢，新增索引后同数据/负载测p95下降，同时写延迟上升；是否接受要对读写SLO判断。上线后大客户数据增长导致回表变多，应按租户规模分组定位，而非只看全局平均。
规模与取舍
压测运行量按请求速率×时长，结果标签基数与日志量需预算；优化理论复杂度与真实硬件/IO证据一起判断。
易错点与追问
容易失分的边界
- 只报平均延迟。
- 前后缓存/数据条件不同。
- 排除超时请求造成假好成绩。
继续深挖
- 怎样识别coordinated omission？
- 持续浸泡能发现什么？
- 怎样区分回归与环境噪声？
