Azure DocumentDB按ID跨分区查询极慢问题求助

嘿，我之前也碰到过类似的Cosmos DB性能问题，结合你的场景给你几个落地性强的解决方案：

首先先纠正一个小误区：Cosmos DB里的id字段是默认自动索引的，除非你在自定义索引策略里明确把它排除了。如果你的索引策略没包含id，那查询时肯定会全分区扫描，速度自然慢。不过不管当前索引情况如何，下面这几个方案都能帮你优化：

方案1：给ID加复合索引，针对性优化跨分区查询 #

如果你的查询是SELECT * FROM c WHERE c.id = @id这种跨分区查询，可以在自定义索引策略里给id加个复合索引，指定排序规则，这样Cosmos DB能更高效地跨分区定位文档。修改后的索引策略大概是这样：

{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    {
      "path": "/*"
    }
  ],
  "compositeIndexes": [
    [
      {
        "path": "/id",
        "order": "ascending"
      }
    ]
  ]
}

要是你之前的索引策略特意排除了id，记得先把它加到includedPaths里，或者直接用/*包含所有路径（如果业务允许的话）。

方案2：存ID和分区键的映射关系，转成单分区查询 #

既然带分区键的查询速度快，那可以专门建个小集合，用来存id到对应分区键的映射。每次要按ID查询时，先查这个映射集合拿到分区键，再用「分区键+ID」去查主集合，瞬间变成单分区查询，性能直接拉满。

举个例子，映射文档的结构可以很简单：

public class IdPartitionMap
{
    public string id { get; set; } // 对应主文档的ID
    public string PartitionKeyValue { get; set; } // 主文档的分区键值
}

写入主文档的时候，用TransactionalBatch把主文档和映射文档一起写入，保证原子性；查询的时候先查映射，再查主文档就行。这个方案的好处是映射集合数据量极小，查询几乎秒出。

方案3：给ID建全局二级索引（GSI） #

如果你的自定义索引策略没包含id，直接给id建个全局二级索引就行。GSI是跨分区的，能让Cosmos DB快速定位到所有分区里匹配ID的文档。调整索引策略的时候，把/id加到包含路径里：

{
  "includedPaths": [
    {
      "path": "/id/*"
    }
  ]
}

或者直接在Azure门户的索引策略编辑器里操作，可视化添加更方便。

方案4：长期优化：调整分区策略 #

如果你的业务经常需要按ID跨分区查询，那可能当前的分区键选得不太合理。可以考虑让分区键和ID关联，比如用ID的哈希前缀当分区键，这样按ID查询时能算出对应的分区范围，减少扫描的分区数。不过这个方案需要迁移数据，属于长期优化，得评估成本后再做。

最后给你个小技巧：用Azure门户的查询性能分析器看看你的查询执行计划，如果显示RID Lookup或者Full Scan，那百分百是索引的问题，调整索引策略就能解决。

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