CouchDB查询优化：解决索引命中反而查询耗时更长问题

问题背景 #

CouchDB中存储的几何数据对应C#类定义如下，Geometry类继承自CouchDocument，嵌套的Definition类仅存储点位列表与基础属性：

public class Geometry : CouchDocument
{
    public Guid SyncId { get; set; }
    public DateTimeOffset CreatedOn { get; set; }
    public Definition Definition { get; set; }
}

• SyncId为跨微服务识别几何数据的唯一标识，计划作为文档主键使用
• 已创建的JSON二级索引如下：

{
   "index": {
      "fields": [
         "syncId"
      ]
   },
   "name": "sync-id-index",
   "type": "json"
}

• 查询出现反常表现：使用$in操作符、或syncId=X1 OR syncId=X2语法查询时，索引正常命中，但耗时达16秒；删除该索引后全表查询耗时仅4秒。使用的查询语句如下：

{
   "selector": {
      "syncId": {
         "$in": [
            "ca7be6e4-dc11-4ddf-99f3-c97f544bf998",
            "716726b9-5493-498c-b207-d4b7e63f1ef3",
            "cb6c4941-7b33-445b-8988-361930f9b39a",
            "564fc2d5-3713-4b2b-b2e5-7dd79ef4509c",
            "6c9845e3-39fa-4a3f-acb7-86a362665a13",
            "15bb9836-3bd1-42b3-b12c-5a1025490d20",
            "a0e15e75-292f-4c76-959f-8adc5e569a31",
            "39b056bf-4ff9-4ada-9a44-9552801b52c4",
            "20d9e3bf-3e32-4426-850a-86422771897a",
            "9f262c8c-e493-4bec-9871-ed612a698a8c"
         ]
      }
   }
}

优化方案 #

• 核心修正：直接将SyncId作为CouchDB内置的_id主键字段存储，不要额外在文档体中存储syncId字段再创建二级索引。CouchDB的_id字段自带原生B树主索引，是查询效率最高的索引结构，无需额外维护。
  现有性能问题的原因很明确：二级索引查询需要先遍历索引树匹配到对应文档的_id，再根据_id回主存储读取完整文档，多了一次回表开销；加上$in操作需要在二级索引上做多次离散查找，当返回结果占总数据量比例不低时，二级索引查询的总开销反而比顺序全表扫描更高。
• 替换查询接口：将SyncId设为_id后，不要使用Mango语法的$in查询，直接调用CouchDB原生的批量文档接口POST /{db}/_all_docs，把待查询的ID放在请求体的keys数组中，设置include_docs: true即可返回完整文档。该接口直接读取主索引，没有Mango查询的额外解析、回表开销，10个ID的查询通常可以做到毫秒级返回。调用示例：

curl -X POST http://<your-couchdb-instance>/<your-db-name>/_all_docs \
  -H "Content-Type: application/json" \
  -d '{
    "include_docs": true,
    "keys": [
      "ca7be6e4-dc11-4ddf-99f3-c97f544bf998",
      "716726b9-5493-498c-b207-d4b7e63f1ef3",
      "cb6c4941-7b33-445b-8988-361930f9b39a",
      "564fc2d5-3713-4b2b-b2e5-7dd79ef4509c",
      "6c9845e3-39fa-4a3f-acb7-86a362665a13",
      "15bb9836-3bd1-42b3-b12c-5a1025490d20",
      "a0e15e75-292f-4c76-959f-8adc5e569a31",
      "39b056bf-4ff9-4ada-9a44-9552801b52c4",
      "20d9e3bf-3e32-4426-850a-86422771897a",
      "9f262c8c-e493-4bec-9871-ed612a698a8c"
    ]
  }'

• 兼容历史数据的临时方案：如果短期内无法修改_id生成规则，按以下方式调整：
  1. 删除现有单字段syncId索引，创建覆盖索引，将所有需要返回的字段都加入索引字段列表，比如需要返回SyncId、CreatedOn、Definition时，索引字段设为["syncId", "CreatedOn", "Definition"]，查询时直接从索引即可拿到全部数据，消除回表开销。
  2. 查询时通过use_index参数显式指定使用该覆盖索引，同时通过fields参数只返回实际需要的字段，避免读取不需要的大字段增加IO开销。
• 注意事项：CouchDB Mango查询对$in操作符的优化上限很低，只要是已知主键批量取数的场景，优先使用_all_docs接口，性能远高于Mango查询。

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