知识点深化 · 性能成本调优
性能成本调优：Profile 定位、缓存策略、LLM 降本三板斧、压测量化
客户投诉"慢"和"贵"是 FDE 最常面对的两个问题。这一页不讲理论公式，只讲现场实战：先量后改的优化闭环、后端性能三板斧（SQL/缓存/异步）、LLM 降本三板斧（选模型/精简Prompt/缓存）、压测前后对比用数据说话。
① 小白第一课怎么学（5 步走，约 90 分钟）
核心心法：先量后改，不要凭感觉优化。
1建立优化闭环认知（15 分钟）
读②③：基线→Profile→改→验证。
2后端性能三板斧（25 分钟）
读④：SQL/缓存/异步。
3LLM 降本三板斧（25 分钟）
选模型/精简Prompt/缓存。
4压测验证（15 分钟）
改完要量，用数据说话。
5刷题巩固（10 分钟）
做⑥⑦⑩。
本课小目标学完你要能：① 按"基线→Profile→改→验证"闭环做优化；② 定位慢查询并加索引；③ 正确使用缓存并处理三大坑；④ 用三板斧把 LLM 成本降一半。
② 一图看懂：性能成本优化闭环
读法：先量现在多慢多贵 → Profile 找到瓶颈 → 动手优化 → 压测对比验证。别跳步。
③ 本质直觉：优化就是"别做重复的事"
性能慢、成本贵，本质都是"在做重复的、不必要的计算"。
后端慢：同一个 SQL 跑了 1000 遍（没缓存）、大表全表扫描（没索引）、同步等外部 API（没异步）。
LLM 贵：简单任务用了最贵的模型（杀鸡用牛刀）、每次都把 8000 token 的文档全塞进去（RAG 没剪）、同一个问题问了 100 遍（没缓存）。
优化的本质就是消除重复：算过一次的结果存下来（缓存）、便宜能搞定的别用贵的（模型分级）、能异步的别同步等（异步化）。
80/20 法则20% 的代码导致了 80% 的耗时和成本。优化要找到那 20%，不是平均优化所有地方。
④ 完整体系：后端三板斧 + LLM 三板斧
后端性能三板斧
| 手段 | 解决什么 | 怎么做 |
|---|
| SQL 优化 | 数据库慢查询 | 慢查询日志找瓶颈、加索引、消除 N+1 |
| 缓存 | 重复查询打 DB | Redis 缓存读多写少数据，设过期+删缓存 |
| 异步化 | 同步阻塞拖慢主流程 | 非核心路径改 MQ 异步，主流程快速返回 |
缓存三大坑
| 坑 | 现象 | 解法 |
|---|
| 缓存穿透 | 查不存在的 key 每次打 DB | 空值缓存短过期 / 布隆过滤器 |
| 缓存雪崩 | 大量 key 同时过期打 DB | 过期时间加随机偏移 |
| 缓存击穿 | 热点 key 过期瞬间打 DB | 互斥锁重建 / 永不过期+后台更新 |
LLM 降本三板斧
| 手段 | 省多少 | 做法 |
|---|
| 模型分级 | 10~15 倍 | 简单任务用 gpt-4o-mini，难任务才用大模型 |
| Prompt 精简 | 30~50% | RAG 只取 top-3，历史对话做摘要，设 max_tokens |
| 结果缓存 | 命中率 30~50% | FAQ 类问题结果缓存 1 小时 |
成本计算公式
LLM 单次成本
成本 = 输入tokens × 输入单价 + 输出tokens × 输出单价
慢查询定位 SQL
-- PostgreSQL 查最耗时 SQL
SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC LIMIT 10;
-- 看执行计划
EXPLAIN ANALYZE SELECT * FROM orders
WHERE user_id = 123 AND status = 'paid';
-- 看到 Seq Scan 就要加索引
⑤ 用法场景与典型例题
例1（后端慢定位）一个列表接口要 3 秒，你怎么找瓶颈？
分层打时间戳，先看哪层最慢。
① 加 timing 中间件，打印 DB 查询时间、外部调用时间、业务时间。
② DB 占了 2.5 秒 → 查 pg_stat_statements 找慢 SQL，看有没有缺索引、N+1。
③ 外部 API 占了 2 秒 → 能不能并行调用？能不能加缓存？
④ 业务逻辑占了 2 秒 → cProfile 跑一下。
答案：分层定位，别凭感觉猜。
例2（缓存一致性）更新数据库后，缓存怎么处理？
先更 DB 再删缓存。
① 读路径：先查缓存，miss 再查 DB，然后回填缓存。
② 写路径：先更新 DB，再删除缓存（不是更新缓存）。
③ 为什么删不更：并发写时更新缓存容易写脏；删了下次读自然拉新的。
答案：先更 DB，再删缓存。
例3（LLM 降本）客户月账单从 $200 涨到 $2000，怎么降？
三板斧齐上。
① 查用量分布：按功能/用户/模型拆，看哪部分涨最多。
② 简单任务换小模型（分类/提取用 gpt-4o-mini）。
③ 精简 Prompt：RAG 只留 top-3，历史对话做摘要。
④ 加结果缓存：FAQ 类命中直接返回。
答案：模型分级 + Prompt 精简 + 结果缓存。
⑥ 高频错误诊断（4 条）
错误 1：凭感觉优化觉得某个地方慢就去改，改完没提升。正确做法是先建基线、Profile 定位，找到那 20% 的瓶颈再动手。
错误 2：缓存穿透/雪崩不管查不存在的 key 每次打 DB、大量 key 同时过期瞬间打垮 DB。要做空值缓存、过期时间加随机。
错误 3：所有任务都用最贵的模型分类、提取这种简单任务也用 GPT-4o，成本翻 15 倍。要按任务难度分级选模型。
错误 4：改完不验证说"应该快了"就上线。必须压测前后对比，用数据说话——p99 降了多少、QPS 涨了多少。
⑦ 考点真题演练（4 题）
考点分布
| 考法 | 出题形式 | 应对 |
|---|
| 优化闭环 | 优化步骤排序 | 基线→Profile→改→验证 |
| 缓存坑 | 穿透/雪崩/击穿区分 | 各自解法要记清 |
| LLM 降本 | 怎么降成本 | 三板斧 |
| SQL 优化 | 慢查询怎么处理 | 找慢SQL+加索引 |
真题基础1. 性能优化的正确第一步是？
真题中档2. 大量缓存 key 同时过期，瞬间打垮数据库，这叫什么？
真题中档3. 更新数据库后，缓存应该怎么处理？
真题拔高4. 下列哪个不是 LLM 成本优化的手段？
⑧ 必背知识点卡
优化闭环：基线→Profile→改→验证 别凭感觉
80/20：20%代码导致80%耗时 找瓶颈别平均用力
后端三板斧：SQL优化 + 缓存 + 异步化 消除重复
缓存三坑：穿透(空值缓存)/雪崩(加随机)/击穿(互斥锁) 先删后更
LLM三板斧：选对模型 + 精简Prompt + 结果缓存 省一半
验证：改完压测前后对比 用数据说话
⑨ 应用输出：优化一个慢接口
场景：订单列表接口 p99 要 3 秒，用户投诉慢
① 建基线：当前 p99=3.2s，QPS=50，DB CPU 80%。
② Profile 定位：加中间件打时间戳，发现 DB 查询占 2.8 秒。查 pg_stat_statements，是一个 JOIN 查询没有索引。
③ 优化 1：加复合索引 (user_id, status, created_at)，SQL 从 2.8s 降到 0.3s。
④ 优化 2：热点用户的订单列表加 Redis 缓存，过期 60 秒，读请求 70% 命中缓存。
⑤ 验证：压测后 p99=0.5s，DB CPU 降到 30%，成本没涨。
口述优化思路"先量现在多慢，Profile 找到是 DB 慢 SQL，加索引 + 加缓存，改完压测验证 p99 降了多少。"
⑩ 分层练习 15 题（基础 5 + 中档 5 + 拔高 5）
▍基础 5 题
基础1性能优化第一步做什么？
建基线+Profile，先量清楚现在多慢、瓶颈在哪，不要凭感觉改。
基础280/20 法则在优化里什么意思？
20% 的代码导致了 80% 的耗时。优化要找到那 20%，不是平均优化所有代码。
基础3缓存穿透是什么？
查不存在的 key，每次都打到数据库。解法：空值也缓存（短过期），或布隆过滤器。
基础4缓存雪崩是什么？
大量 key 同时过期，瞬间全打到 DB。解法：过期时间加随机偏移，不要一起过期。
基础5更新 DB 后缓存怎么处理？
删除缓存（不是更新缓存）。下次读自然从 DB 拉新的，避免写脏。
▍中档 5 题
中档6慢查询怎么定位？
开慢查询日志，用 pg_stat_statements 找最耗时 SQL，EXPLAIN ANALYZE 看执行计划，看到 Seq Scan 就加索引。
中档7N+1 查询是什么？怎么解？
列表里循环一条条查关联数据。解法：JOIN 一次查出来，或用 IN 批量查。
中档8LLM 成本怎么降？
三板斧：① 简单任务换小模型；② 精简 Prompt 减少 token；③ 结果缓存。批量任务走 Batch API 半价。
中档9什么任务适合用便宜的小模型？
分类、信息提取、格式转换这种简单任务。复杂推理、写代码、RAG 难问题才用大模型。
中档10结果缓存适合什么场景？
高频重复问题（FAQ）、确定性任务。对话类、个性化场景命中率低，意义不大。
▍拔高 5 题
拔高11缓存击穿和雪崩的区别？
击穿=单个热点 key 过期瞬间打 DB；雪崩=大量 key 同时过期。击穿用互斥锁重建，雪崩加随机过期时间。
拔高12为什么优化完必须压测验证？
不然不知道到底快了多少，也不知道有没有改坏。用数据说话：p99 降了多少、QPS 涨了多少、有没有引入新问题。
拔高13RAG 怎么减少输入 token？
top-K 别取太多（3 段够了）、分块别太大、历史对话做摘要、检索结果先去重。
拔高14为什么不建议过度优化？
优化有成本（开发时间、复杂度）。没到瓶颈就优化是浪费。先有量，找到真实瓶颈再动手。
拔高15本地部署大模型怎么提速？
用 vLLM 连续批处理、量化（INT8/INT4）、KV Cache 复用、合理设并发和显存利用率。
⑪ 记忆口诀 + 7 天复习计划
三句口诀
① 先量后改别瞎猜，Profile 找那 20%。
② 后端三板斧：SQL、缓存、异步化。
③ LLM 三板斧：选模型、减 token、加缓存。
| 天 | 任务 | 自检 |
|---|
| 第 1 天 | 读②③，画优化闭环图 | 能说清四步 |
| 第 2 天 | 背缓存三坑 + 做基础 1-5 | 基础全对 |
| 第 3 天 | 写一个缓存读写代码 | 先删后更 |
| 第 4 天 | 做中档 6-10，理解 LLM 降本 | 会算省多少钱 |
| 第 5 天 | 做拔高 11-15 + 真题 4 题 | 会定位慢查询 |
| 第 6-7 天 | 口述一个慢接口优化方案，默写三板斧 | 不看资料全默对 |
← 返回 FDE 培养总览