解读

面试官想考察的是：

1. 你是否把“可接受”当成一个业务问题，而非纯技术指标；
2. 能否用国内主流可观测体系（Prometheus+Grafana、CAT、SkyWalking、ARMS 等）给出量化证据；
3. 是否熟悉 SLA/SLO 的国家标准、行业惯例及公司内部基线；
4. 能否把“RT 线性增长”反向拆解到代码、索引、线程模型、资源配比，给出闭环方案。

知识点

1. SLA 与 SLO：国内金融、电信、政企云普遍采用《GB/T 34982-2017 信息技术 云计算 服务运营通用要求》+ 集团内部红线，如电商大促“核心读接口 P99 ≤ 300 ms，写接口 P99 ≤ 800 ms”。
2. 线性可扩展模型：若数据量 ×10，RT ×10，则吞吐 TPS 必然下降 10 倍，已违反“水平扩展应保证 RT 不变或微增”原则。
3. 拐点分析：通过 Little 定律 L = λ×W，结合 CPU 利用率、DB 逻辑读、线程阻塞占比，定位是算法复杂度退化还是资源饱和。
4. 国内常用压测工具链：JMeter + Gatling 做负载，DTS/DataX 灌数，PTS 或 HyBench 做容量，ARMS/SkyWalking 做链路 Profiling。
5. 可接受判定四步法：业务阈值比对 → 成本收益测算 → 风险分级 → 决策记录（邮件+Confluence 留痕）。

答案

第一步：确认基准

1. 取出上线前容量报告中的“数据量-RT 基线”与 SLO。例如：单表 500 万行时 P99=120 ms，SLO 为 P99≤300 ms。
2. 10 倍后即 5000 万行，若 P99=1.2 s，已超 SLO 4 倍，直接判定“不可接受”。

第二步：验证线性增长是否由业务允许

1. 若该接口仅在月初批跑场景触发，且上游可接受 2 s 延迟，则与产品经理重新签订临时 SLA，降级为“低优先级债务”，可“暂时接受”，但需给出还款计划。
2. 若接口位于用户下单黄金链路，任何超过 300 ms 的放大都会带来转化率下跌（国内阿里、京东 AB 实验数据：每增加 100 ms 支付转化率下降 1.1%），则无论是否线性，都“不可接受”。

第三步：资源成本测算

1. 线性增长意味着 O(n) 复杂度，继续膨胀到 5 亿行 RT 将 20×，需 20 台应用+20 只只读实例，成本 120 万/年。
2. 若把热点字段加二级索引+覆盖索引，把 O(n) 降为 O(log n)，只需追加 2 台 RDS 只读，成本 12 万/年，ROI 高，则“当前不可接受，但可优化后接受”。

第四步：风险分级与决策

1. 出具《性能风险评估报告》：红（>SLO 3 倍）、橙（1~3 倍）、黄（<1 倍）。
2. 召集架构、运维、产品、安全四方评审，邮件结论：
   “数据量 10× 后 RT 线性增至 1.2 s，超出 SLO 300 ms 基线 4 倍，风险等级红，不可接受；限 3 个迭代内完成索引重构+分页+缓存预热，目标 P99≤300 ms，否则启动限流+降级。”

结论话术：
“仅凭‘线性’无法判断是否可接受，必须对照已发布的 SLA、业务容忍度、成本边界和合规要求。若 10× 数据量导致 RT 突破 SLO 或使吞吐量跌破业务最低值，即判定不可接受，并推动在下一版本完成算法或架构优化。”

拓展思考

1. 如果数据量继续 100×，而 RT 仍保持线性，你会提前做哪些容量预案？
2. 如何向管理层解释“RT 线性增长”与“指数增长”对云资源预算的不同影响？
3. 在国产数据库（OceanBase、TiDB、PolarDB-X）场景下，同样的 SQL 执行计划是否会改变线性趋势？如何利用 Hint 或分区键重选打破线性？