好的，所以CosmosDb Collection将它的索引策略设置为一致，自动，具有默认的哈希和范围索引 AND 我们为自己的时间戳属性添加了一个路径，以便按它们排序。
我知道路径是正确的，因为我无法通过它们订购，除非我设置它们。但是：
按Cosmos内置属性 _ts 排序时 - OrderBy查询的费用类似于 20 RU / s 。那很棒。 现在，按我们的 OWN 时间戳列排序时（我们有两个，其中一个是字符串时间戳，另一个是基于Unix的数字，就像内置的 _ts 柱。 此查询的费用 400 RU / s！???
使用新的索引规则可以让我们查询和订购它，但 RU 是疯了。为什么这样，我们如何解决它？
我知道您之前无法更改索引政策Ad Hoc，但已根据Microsoft解决此问题。
编辑：这是一个简单的集合，没有配置分区，查询只针对这个集合运行，只选择一个文档（前1个）。
SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c.EndFetchDateTimeUtcUnix DESC
VS
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": []
}
答案 0 :(得分：0)
这可能是您遇到索引冲突（多个值映射到同一索引术语）的情况。
为了最大限度地减少碰撞的可能性，并且如果订购商品已知最小/最大值，您可以在订购商品上添加过滤器，以缩小检索到的索引字词的范围。
例如，
SELECT * 来自c WHWE c.DateTime BETWEEN＆＃39; 2000-01-01T00：00：00.0000000Z＆＃39; AND＆＃39; 3000-01-01T00：00：00.0000000Z＆＃39; 订购c.DateTime
同样，您可以将相同的技术应用于数字时间戳。
答案 1 :(得分：-1)
我建议你研究一下DocumentDB花费多少精力。转到Query execution metrics标题以获取线索。