在 SaaS 平台上，全文检索与复杂多维查询是用户的刚需。Elasticsearch (ES) 作为业内主流的搜索引擎，经常被引入来承担海量业务数据的检索工作。在面对成百上千个租户时，如何设计索引架构以兼顾查询性能、数据隔离和集群稳定性，是工程实现上的重点。
ES 的多租户索引策略一般分为三种：单索引共享（Shared Index）、按租户独立索引（Index-per-Tenant）以及按时间/业务维度的混合路由策略。
按租户独立索引的做法逻辑最为简单，每个租户的数据完全隔离在独立的 Index 中。由于不需要在查询中额外附加租户条件，数据安全性最高。然而，ES 集群中每一个 Shard 都会占用操作系统的文件句柄和 JVM 堆内存。如果系统中有数千个租户，即使大多数是长尾小租户，依然会产生数以万计的 Shard，导致集群元数据（Cluster State）极度膨胀。这种情况下的集群状态更新会变得非常缓慢，最终引发内存溢出或节点假死。
单索引共享架构则将所有租户的数据写入同一个 Index，通过在文档中增加 tenantid 字段来进行逻辑隔离。这种方式最大程度地减少了 Shard 数量，对集群资源最为友好。查询时，只要强制加上 term: { "tenantid": "xxx" } 即可。但这带来了另外两个问题：一是不同租户可能具有不同的自定义字段，混合在一起容易触发 Mapping Explosion（字段总数超出限制）；二是单个大租户的数据可能会使该 Index 变得异常庞大，影响小租户的查询性能。
工程界更为推崇的做法是基于自定义路由（Custom Routing）的混合架构。数据写入时，通过指定 routing=tenant_id，确保同一个租户的数据始终落在同一个 Shard 上。在查询时携带相同的 routing 参数，ES 只需要将请求发送到包含该数据的单一分片，避免了 Scatter-Gather（广播-聚合）过程，极大地提升了查询吞吐量。
对于数据量庞大的头部租户和长尾租户，橙星云技术团队通常会采用分层策略。针对体量占极高比例的 VIP 租户，分配专用的索引或节点组，确保其复杂查询不会消耗公共资源池；对于数量众多的小租户，则将它们打包路由到按业务线或时间切分的共享索引中，配合自定义路由优化查询。
在处理字段映射方面，为应对租户动态添加自定义字段的需求，建议避免使用 ES 的动态映射（Dynamic Mapping）。取而代之的是采用 Nested 类型或扁平化的键值对结构（如 key1, value1, key2, value2），将结构化的业务字段转换为非结构化的索引存储，从而规避 Mapping 爆炸的风险。无论采用哪种架构，都需要配合完备的别名（Alias）机制，将底层索引的物理变更对应用程序透明化，以支持零停机的数据重组与集群迁移。