Azure Search多租户用单一索引、单数据源存储QnA是否可行？

你提到的多租户共享单索引、共享单存储（通过唯一租户键做查询过滤区分）的方案在技术上是完全可行的，也是Azure官方推荐的低成本多租户架构选项之一，但该方案存在以下明确弊端：

• 数据隔离风险高：这是该方案最核心的隐患。所有租户数据存储在同一索引和Azure Table Storage表中，一旦查询逻辑漏加租户键过滤、RBAC权限配置失误，就会直接出现租户间数据泄露问题。同时该模式无法为单个租户配置独立的客户管理密钥（CMK），无法满足金融、医疗等强监管行业的数据隔离合规要求。
• 租户间性能相互影响：单个索引和存储表的算力、IO资源上限是固定的，任意租户的大流量查询、全量数据写入操作都会占用共享资源，直接拉低所有其他租户的查询响应速度，甚至导致请求超时。
• 租户级运维灵活性差：无法针对单个租户做独立的索引配置调整，比如自定义分词规则、自定义搜索评分逻辑、独立数据备份恢复，也无法单独为高价值租户提升搜索资源配额。如果需要删除单个租户的所有数据，只能执行带过滤条件的批量删除操作，操作风险和复杂度远高于直接删除独立索引/独立表。
• 查询性能随规模衰减：当单索引总文档量达到千万级以上时，每次查询都需要额外执行租户键过滤，即使租户键字段已配置为可过滤属性，查询延迟也会明显高于单租户独立索引方案；同时Azure Table Storage的查询性能也会随单表总数据量上升出现明显衰减。
• 存在容量天花板：Azure AI Search的单个索引有明确的文档数、存储容量上限（不同SKU上限不同，比如标准S3 SKU单索引最多支持2亿文档、1TB存储），当总租户数据量触及上限时，需要做数据拆分迁移，改造成本远高于独立索引架构。
• 故障影响范围广：如果共享索引或共享存储表出现服务故障，所有租户的搜索服务会同时不可用，无法实现租户级的故障隔离。

内容的提问来源于stack exchange，提问作者ChinnarajS