Azure Cosmos DB子队列关联查询RUs过高，求优化方案

针对你遇到的查询RUs居高不下的问题，结合你的文档结构和查询语句，我整理了几个可行的优化方向：

1. 拆分OR条件为UNION ALL查询 #

原查询中的OR条件涉及两个不同的关联属性（advisor.id和technician.id），Cosmos DB在处理这类跨属性OR的JOIN查询时，索引利用率往往不高。将查询拆分为两个独立子查询再用UNION ALL合并，能让每个子查询更高效地利用索引：

SELECT q.id FROM c JOIN q IN c.subQueue 
WHERE c.facilityId = 'b554197f-868d-4f22-9115-19f2bc5a356b' 
AND q.id = 5 
AND c.advisor.id = '01eac7a6-aa21-4f08-a9fa-0449adeae2e3'

UNION ALL

SELECT q.id FROM c JOIN q IN c.subQueue 
WHERE c.facilityId = 'b554197f-868d-4f22-9115-19f2bc5a356b' 
AND q.id = 8 
AND c.technician.id = '0366949b-15ee-400a-bc39-ca792ef9fecb'

这种拆分后，每个子查询的过滤条件更单一，Cosmos DB可以精准匹配对应的索引，避免不必要的文档扫描。

2. 调整复合索引策略 #

你提到已为subQueue.id创建复合索引，但当前查询的过滤条件组合是facilityId + (advisor.id/technician.id) + subQueue.id，单一的subQueue.id索引无法覆盖整个过滤逻辑。建议创建两个针对性的复合索引：

索引1（对应第一个子查询） #

{
  "indexingMode": "consistent",
  "includedPaths": [
    {
      "path": "/facilityId/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "String",
          "precision": -1
        }
      ]
    },
    {
      "path": "/advisor/id/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "String",
          "precision": -1
        }
      ]
    },
    {
      "path": "/subQueue/id/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "Number",
          "precision": -1
        }
      ]
    }
  ]
}

索引2（对应第二个子查询） #

{
  "indexingMode": "consistent",
  "includedPaths": [
    {
      "path": "/facilityId/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "String",
          "precision": -1
        }
      ]
    },
    {
      "path": "/technician/id/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "String",
          "precision": -1
        }
      ]
    },
    {
      "path": "/subQueue/id/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "Number",
          "precision": -1
        }
      ]
    }
  ]
}

如果希望进一步优化，可以将q.id加入覆盖索引的includedPaths，避免查询时回表读取完整文档；甚至可以设置excludedPaths排除无关字段，减少索引存储和查询开销。

3. 验证基础索引是否存在 #

首先确认facilityId是否有单独的范围索引——这是查询的第一个过滤条件，如果没有索引，Cosmos DB会先扫描该容器下的所有3000条文档，这会大幅提升RUs消耗。默认情况下Cosmos DB会为所有属性创建索引，但如果你修改过索引策略，需要确保/facilityId/*在includedPaths中。

4. 检查查询执行计划 #

在Azure Portal的Cosmos DB资源中，打开数据资源管理器，执行你的查询后查看查询执行计划：

• 确认是否显示“使用索引”（Using Index），如果显示“全表扫描”（Full Scan），说明索引未被正确利用，需要调整索引策略。
• 查看“已加载文档数”（Documents Loaded），理想情况下应该远小于3000，否则说明过滤条件没有有效筛选文档。

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