性能分析最容易掉进两个陷阱：一个是“看到慢就先加缓存”，另一个是“看到 SQL 就先改索引”。这两种反应都不完全错，但都太快了。AI 在这一课真正能帮上的，不是替你直接定优化策略，而是帮你解释现象、归纳访问模式、组织实验和记录取舍。
真实研发场景
真正难的不是没有建议，而是不知道先看哪一层
线上接口开始变慢时，团队经常同时听到好几种声音：有人说应该先查 SQL，有人说应该先上缓存，有人觉得可能是检索链路慢，还有人怀疑是模型调用本身。每个方向都可能有道理，但如果没有先把请求路径、热点访问、命中率和延迟来源拆开看，优化动作就很容易打在错误层上。
AI 在这里最稳的价值，是把“现象”翻译成“待验证的性能假设”，帮助工程师避免凭直觉先动刀。
本课重点是“先解释现象，再做实验”
性能问题里最贵的，不一定是分析慢，而是错误优化。你可能花了很多时间加缓存，却引入失效复杂度；也可能为了一个偶发慢查询改了索引，却没解决真正的热点访问模式。AI 应该帮助你更快理解现象和实验设计，而不是跳过证据直接给出“最优方案”。
传统做法的痛点
错误优化会把复杂度加到错误层
| 习惯性动作 | 短期看起来解决了什么 | 长期可能带来的问题 |
|---|---|---|
| 先加缓存 | 暂时降低读延迟 | 一致性、失效和命中率问题增加 |
| 先改 SQL | 看起来更专业 | 如果热点不在数据库，收益很低 |
| 先怀疑模型调用 | 容易归因给外部服务 | 忽略应用层访问模式和重试 |
| 只做一次分析 | 有了建议文本 | 没有实验和数据验证，无法沉淀 |
性能问题最怕的不是不知道，而是只知道“一个方向”。
AI 参与性能分析时常见的三个误区
- 让 AI 直接决定索引、缓存键或 TTL
- 没有准备请求量、慢点分布、命中率等证据就开始问优化
- 只保留建议文本，不记录为什么采纳或放弃
AI 能提效到哪一步
AI 最适合参与的分析动作
- 解释 SQL 或访问路径：帮助工程师快速看懂查询意图和潜在风险
- 归纳热点模式：例如读多写少、重复查询、检索双通路合并
- 草拟缓存候选：列出适合缓存的对象、键粒度和潜在失效风险
- 组织性能检查单：帮助你把实验前提和验证指标写清楚
不适合直接交给 AI 拍板的部分
| 决策 | 为什么必须人工判断 |
|---|---|
| 是否引入缓存 | 取决于一致性成本和维护成本 |
| 是否改索引或改表结构 | 取决于真实查询分布和业务写入代价 |
| 是否接受性能退化 | 取决于 SLA、流量和业务影响 |
| 是否更换实现策略 | 需要结合团队维护能力和上线风险 |
一个很实用的规则是：AI 可以给你实验候选，但不能替你跳过实验。
推荐工作流
先准备“现象包”，不要只准备一段 SQL
建议至少准备这些信息：
- 请求路径或调用链
- SQL 或检索逻辑
- 延迟、命中率、访问量等基础指标
- 当前缓存或无缓存策略
- 你已经观察到的异常模式
五步性能分析法
| 步骤 | AI 产出 | 人工要做什么 | 验证方式 |
|---|---|---|---|
| 1. 解释现象 | 路径说明、潜在瓶颈清单 | 删掉与现象无关项 | 是否能明确慢在哪一层 |
| 2. 归纳访问模式 | 热点、重复读、写读比例说明 | 结合业务量级修正 | 是否足以支持缓存或索引假设 |
| 3. 提实验方案 | SQL 优化、缓存候选、采样建议 | 选择一两个最值得验证的实验 | 是否有清晰验证指标 |
| 4. 做真实验证 | 运行实验或观察指标 | 记录前后差异 | 命中率、耗时、错误率是否改善 |
| 5. 沉淀取舍 | 最终策略与放弃理由 | 写入文档或检查表 | 下次是否可复用 |
一个适合性能分析阶段的输入模板
请求路径：
观察到的现象：
相关 SQL / 检索逻辑：
已有指标：
当前缓存策略：
请输出：
1. 现象解释
2. 值得验证的优化候选
3. 每个候选的风险与验证指标
与仓库代码和模板的映射
- 只读 SQL 预览：
../demo/src/main/java/com/example/ainative/dataassistant/controller/SqlAssistantController.java适合讨论 SQL 分析为什么要先守住只读边界。 - 会话缓存：
../demo/src/main/java/com/example/ainative/cache/SessionMemoryStore.java适合说明缓存并不只是“加一层 Map”，而是行为与失效策略设计。 - 混合检索：
../demo/src/main/java/com/example/ainative/knowledge/retrieve/HybridRetriever.java适合观察多路召回和结果合并可能带来的性能取舍。 - 指标收集：
../demo/src/main/java/com/example/ainative/ops/metrics/AiMetricsFacade.java适合说明没有指标就很难判断优化是否有效。 - SQL 回归样例：
../demo/evals/tools/sql-preview.yaml适合把性能与安全边界一起纳入检查。 - 对应练习：
../课后练习/第7课/练习.md
常见误用与风险
误用一：让 AI 直接决定缓存策略
缓存涉及一致性、淘汰、更新和命中率，不是看起来“适合缓存”就能直接上。
误用二：没有指标，只看建议是否像样
没有真实数据时，所有优化建议都只是候选假设。
误用三：把问题简单归因为“数据库慢”
慢查询只是结果的一部分，问题可能出在访问模式、重复读或调用链设计。
误用四：优化后不记录为什么做、为什么不做
没有取舍记录，下次遇到类似问题时团队还是要重来一遍。
课后练习
建议直接在 ../课后练习/第7课/练习.md 中完成本课练习，并使用 ../课后练习/通用提交模板.md 保留 AI 输入、人工删改和验证结果。
如果你只做最小版交付，也至少保留四样东西：结构化输入、AI 产出摘要、人工判断记录、最终验证结果。
基础题
挑一条 SQL 或热点请求路径，先写一份“现象包”，不要急着给方案。
进阶题
让 AI 基于现象包给出 2 到 3 个优化候选，再人工写出每个候选的风险与验证指标。
挑战题
产出一份性能分析记录，说明最终选择了什么方案、放弃了什么方案，以及依据是什么。