搜索索引、结果集缓存与海量数据检索

搜索系统同时处理文本匹配、过滤、排序和聚合。索引保存的是可检索的结构，不是每个查询的永久结果集；结果缓存需要由业务明确管理。

索引和原始数据分离

原始订单或文章保存在事实库，搜索引擎保存用于检索的字段和文档 ID。索引重建、字段调整和数据修复都依赖事实库或事件日志，不能把搜索索引当成唯一数据源。

倒排索引适合文本和标签，数值索引适合范围过滤，排序字段通常需要额外的列式结构。字段越多，写入和更新成本越高，应按查询需求选择。

结果集什么时候缓存

重复率高、查询昂贵、允许短暂旧数据时，可以把规范化查询条件计算为 Hash：

search:result:{hash} -> 文档 ID 列表 + total + 版本
TTL = 30 秒

缓存只存分页 ID 或聚合摘要，详情再批量读取，避免把大对象复制到缓存。数据更新时可以按索引版本或租户版本失效，减少逐条删除的复杂度。

深分页和游标

使用很大的 offset 会让引擎跳过大量结果并重新排序。推荐使用 search_after、游标或基于排序值的分页。游标是短期查询状态，不应长期充当结果缓存。

聚合的成本

高基数字段聚合会消耗大量内存。对仪表盘固定指标，可以离线预聚合；对实时筛选，限制时间范围、桶数量和并发，超过预算就返回需要缩小范围的提示。

一致性与补偿

业务库写入后通过 CDC 或消息更新索引，期间会存在延迟。搜索结果页要接受短暂不一致，详情页仍从事实库校验状态。索引消费失败进入重试和死信，定期用全量对账修复漏文档。

搜索性能优化不能只看单次查询耗时，还要观察索引大小、刷新延迟、段合并、缓存命中、P99、深分页比例和重建时间。