大促收官：写一份优化案例文档

七段结构：背景（库的量级、业务场景，两三句）-> 现象（谁报的、什么症状，量化成超时/耗时数字）-> 定位过程（用了什么工具拿到哪条 SQL，贴 pg_stat_statements 或慢日志的证据）-> 计划对比（优化前后 explain analyze 并排，标出最贵节点怎么消失的）-> 方案（改了什么、为什么）-> 结果数据（前后耗时对比表）-> 反思（重来会怎么做、监控能不能更早发现）。每一段都要有数字，没有数字的段落删掉重写。

贴 explain analyze 的文本原文即可（截图也行）：优化前的计划标出耗时最大的节点、rows 估算与 actual 的偏差；优化后贴同一条查询的计划，用箭头标出变化（如 Seq Scan -> Index Scan、扫描行数从百万降到 20）。前后并排是关键，单独一张计划说服力减半。

取舍段写法：列至少两个候选方案、各自的代价、一句结论。例：深分页选 keyset 而不是延迟关联，因为后台只有上一页/下一页的场景、keyset 耗时恒定；仪表盘选物化视图而不是优化原查询，因为业务容忍分钟级延迟、而实时优化要动五张表的 join。没有取舍过程的文档 = 没做过选择题，面试官一眼看穿。

口头版结构：一句话现象 -> 定位用了哪两步 -> 方案一句话 -> 结果数字（从 X 到 Y）-> 一句反思。对着手机录 3 分钟再回放：卡壳的地方就是还没想透的地方，回文档补上；第二遍脱稿讲，不许念稿。

简历句式：「用 A 手段把 B 指标从 X 做到 Y」。例：定位并修复后台深分页慢查询，列表接口 P99 从 8s 降到 50ms（keyset 分页 + 延迟关联）；或：为百万订单表设计按月分区归档方案，历史查询扫描量降 90%。X/Y 必须是文档里真实测过的数字--面试官一定会追问这个数字怎么来的。