背景：数据涨上来之后
业务初期用数据库 LIKE 和分页就能查，数据到千万级之后开始变慢，到亿级后 count、深分页和模糊匹配几乎不可用。更麻烦的是多租户场景：不同客户的数据在一个索引里，查询既要快，又不能越权。
核心难点
- 索引膨胀：字段多、文本长，索引体积和写入成本快速上升。
- 过滤优先：先召回再过滤会浪费大量计算，还可能泄露数据。
- 深分页：from + size 越翻越慢，内存压力大。
- 写入刷新：实时性要求高的业务不能等默认刷新间隔。
- 热点：热门查询和热门租户容易打满节点。
方案：索引、查询、权限、缓存
1. 索引建模
按租户和时间做路由，热数据与冷数据分层；文本字段区分分词与 keyword，只对需要检索的字段建索引；高频过滤字段单独抽列，避免整份 JSON 参与扫描。
2. 查询策略
过滤条件优先下推，减少候选集；列表页只返回必要字段，详情按 ID 回表；深分页改用 search_after 或游标；count 按场景估算或缓存，不每次都精确统计。
3. 多租户权限
租户 ID 作为强制过滤条件，由网关统一注入，业务代码不能省略；敏感字段做脱敏或单独索引；跨租户查询走独立审批通道并记录审计。
4. 缓存与热点
热点查询结果短 TTL 缓存，空结果也缓存；对高频租户做限流和隔离，避免单一租户影响整体；慢查询持续采样，按查询模板归并分析。
结果
亿级数据冷热分层与索引治理
多租户租户路由与权限过滤
稳定检索过滤优先与深分页优化
平台稳定支撑亿级数据的检索与权限隔离，深分页和统计类查询的响应明显改善；索引体积、慢查询和热点租户都有持续观测，容量规划从“拍脑袋”变成按数据说话。
复盘
检索平台的性能优化，80% 在设计阶段决定：索引怎么建、过滤怎么下推、权限怎么注入。上线后再调参数，能救急，但救不了模型层面的错误。