好吧，所以CosmosDb Collection将它的索引策略设置为一致，自动，具有默认的哈希和范围索引 AND 我们添加了一个路径到我们自己的时间戳属性，以便按它们排序 .
我知道路径是正确的，因为我无法通过它们订购，除非我设置它们 . 但：
按Cosmos内置属性 _ts 排序时 - OrderBy查询的成本类似于 20 RU/s . 那很棒 . 现在，按 OWN 时间戳列排序时（我们有两个，其中一个是字符串时间戳，另一个是基于Unix的数字，就像内置的 _ts 列一样 . 此查询成本为 400 RU/s !???
使用新的索引规则使我们能够查询和订购它，但RU是疯了 . 为什么这样，我们如何解决它？
我知道您之前无法更改索引策略Ad Hoc，但微软已经解决了这个问题 .
EDIT: 这是一个简单的集合，没有配置分区，查询仅针对此集合运行，只选择一个文档（前1个） .
SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c.EndFetchDateTimeUtcUnix DESC 对
SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c._ts DESC
该指数看起来像这样： { "indexingMode": "consistent", "automatic": true, "includedPaths": [ { "path": "/", "indexes": [ { "kind": "Hash", "dataType": "Number", "precision": 3 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] }, { "path": "/EndFetchDateTimeUtcUnix/?", "indexes": [ { "kind": "Range", "dataType": "Number", "precision": -1 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] } ], "excludedPaths": [] }
2 回答
这可能是您遇到索引冲突（多个值映射到同一索引术语）的情况 .
为了最大限度地减少冲突的可能性，并且如果逐个项目具有已知的最小值/最大值，则可以在逐个订单项上添加过滤器以缩小检索到的索引术语的范围 .
例如，
SELECT * FROM c WHWE c.DateTime BETWEEN '2000-01-01T00:00:00.0000000Z' AND '3000-01-01T00:00:00.0000000Z' ORDER BY c.DateTime
同样，您可以将相同的技术应用于数字时间戳 .
我建议您调查DocumentDB花费的精力 . 转到Query execution metrics Headers 以获取线索 .