搜索引擎性能调优工程师面试宝典 - 第3节
第三章 索引优化与查询调优高频问题
索引与查询是搜索引擎吞吐的核心瓶颈。面试中，不仅考察你是否懂倒排索引原理，更看重你在高并发、低延迟场景下的系统性调优能力。本章围绕索引合并、段管理、倒排压缩、查询重写四个子主题，拆解出3个高频面试问答与1个含全流程话术的真实项目案例。
面试问答 1 · 索引合并与段管理
Q：Lucene 的索引段（Segment）数量过多会导致什么问题？你会如何设计段合并策略？
考察点：段合并原理、合并在写放大与查询性能间的权衡；分层合并 vs 按大小合并的选型逻辑。
回答框架：
- ① 指出问题：过多段会拉高查询时的段加载开销、增加文件句柄 & 内存占用。
- ② 分场景描述：写入密集期适当延迟合并降低写放大；读多写少场景激进合并保查性能。
- ③ 选择策略：按大小合并（TieredMergePolicy）直接覆盖大多数场景，LogByteSizeMergePolicy 用于固定大小。
- ④ 给出调参经验：
mergeFactor、maxMergeAtOnce、segmentsPerTier是核心。
示例回答（80字）：段过多会增加查询时的 SegmentReader 数量，导致 I/O 抖动。我会先分析写入速率与查询延迟曲线：写入再高峰期调大 mergeFactor 至 20 减少写放大，低谷期调回 10 加速段合并。用 TieredMergePolicy 配合 maxMergeAtOnce=10，确保段数稳定在 5～8 个。
可能追问：① 段合并如何保证不影响写入实时性？② 你如何计算最佳段大小？③ 合并且发生 OOM 怎么处理？
面试问答 2 · 倒排压缩算法选型
Q：搜索引擎中倒排索引的压缩算法有哪些？你在业务中如何选择？
考察点：常见压缩算法（VInt、Frame of Reference、Roaring Bitmaps）的核心原理；压缩率与解压速度的 trade-off。
回答框架：
- ① 列举主流算法：Simple-8b、PForDelta、Roaring Bitmaps、VSEncoding。
- ② 明确分类：Block-based（FOR/PFD）适合稠密 ID 序列；Bitmap-based（Roaring）适合稀疏 ID。
- ③ 选型依据：根据倒排列表的分布特征（跨度、密度、重复度）选择。
- ④ 给出落地建议：用 Roaring 替代 BitSet 做交集跳转；用 FOR 压缩连续 IDF 段；用 VInt 做通用 fallback。
示例回答（90字）：我会先采样统计倒排表的平均文档间距。若间距均匀（如 doc id 递增），优先用 Frame of Reference 达到 3-4 倍压缩；若出现大量长间隔，切到 Roaring Bitmaps 做 array/bitmap 混合表示。线上验证：用 FOR 后查询 P99 降低了 18%，堆外内存减少 40%。
可能追问：① Roaring 的 container 切换阈值为什么是 4096？② 压缩对 SkipList 跳表效果有何影响？③ 如何对压缩后的数据进行 seek？
面试问答 3 · 查询重写与优化器
Q：Elasticsearch 的查询重写（Query Rewrite）有什么作用？你能举例说明哪些场景会触发重写？
考察点：查询重写的目的（类型转换、常量折叠、索引加速）；重写对性能的实质性收益；了解 Lucene/ES 的查询优化器策略。
回答框架：
- ① 定性：查询重写是将用户 DSL 转化为高效内部表示的过程，主要做常量折叠、否定下推、子树合并。
- ② 举例：
term对range的重写、bool:must单条件短路、wildcard转前缀查询。 - ③ 效果量化：重写后减少子查询数量、利用 PointValues 或 TermsEnum 跳表跳过无效文档。
- ④ 提醒：重写也可能引入副作用（如对脚本查询无效、低版本 regex 重写死循环），需要配合 profile 分析。
示例回答（70字）：比如用户写 range {gte: 100, lte: 100}，ES 会重写为 term 100，直接走倒排查找而非扫番号。还有 wildcard?abc.* 会重写为前缀查询 + 正则过滤，避免全扫描。
可能追问：① 重写发生在哪个阶段？② 禁用重写（rewrite=scoring_boolean）有何影响？③ 如何通过 Explain API 查看重写结果？
profile=true 检查是否触发预期重写，并针对慢查询在 explain 里验证 rewrite 结果。
项目案例：电商搜索实时索引调优
| 项目名称 | 电商搜索实时索引调优 |
| 业务背景 | 日活 2000 万的电商 app，商品搜索延迟 P99 从 80ms 飙升到 350ms。原因分析发现段数突破 200+，导致查询大量开 SegmentReader。 |
| 规模指标 | 每日写入 5 亿文档（更新+增量），索引总量 2TB；在线查询 QPS 10k+；段合并线程数 4 个。 |
| 技术栈 | Elasticsearch 7.17、Lucene 9.x、G1GC 20G Heap、SSD 裸设备，自定义 merge policy。 |
| 核心难点 | 合并期间频繁触发 Full GC；文档更新导致段标记删除率高（30%）；合并策略未区分热数据和冷数据段。 |
| 面试高频追问 | ① 为什么段数多反而查询慢？（段加载 FST 和 Norms）② 如何对热冷数据设置不同的合并优先级？③ 合并过程中如何控制 I/O 和 CPU 资源避免影响写入？④ 如何验证段合并效果？ |
| 可迁移回答话术 | “我采用分层合并策略：热数据段（最近 5 分钟）暂缓合并，减少写放大；冷数据段按大小合并至 500MB。同时开启 index.merge.scheduler.max_thread_count=1 限制合并并发，配合 indices.merge.scheduler.autoThrottle=true 自适应限流。上线后查询 P99 降至 120ms，Full GC 频率下降 80%。” |