此查询花费 265 RU/s:
选择顶部 1 * FROM c
其中 c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
按 c.StartFetchDateTimeUtc DESC 排序
StartFetchDateTimeUtc 是一个字符串属性，使用 Cosmos API 序列化
此查询花费 5 RU/s:
选择顶部 1 * FROM c
其中 c.CollectPackageId = 'd0613cbb-492b-4464-b66b-3634b5571826'
按 c._ts DESC 排序
_ts 是一个内置字段，一个基于 Unix 的数字时间戳。
示例结果(仅包括此字段和_ts):
"StartFetchDateTimeUtc": "2017-08-08T03:35:04.1654152Z",
“_ts”:1502163306
索引已就位，并遵循如何配置可排序字符串/时间戳的建议和教程。看起来像:
{
"路径": "/StartFetchDateTimeUtc/?",
“索引”:[
{
“种类”:“范围”，
“数据类型”:“字符串”，
“精度”:-1
}
]
}
最佳答案
根据这个article ，“项目大小、项目属性计数、数据一致性、索引属性、文档索引、查询模式、脚本使用” 变量将影响 RU。
所以很奇怪的是不同的属性(property)花费不同的RU。
我还在我这边创建了一个测试演示(使用您的索引和相同的文档属性)。我已将 1000 条记录插入到 documentdb 中。两个不同的查询花费相同的 RU。我建议你可以开始一个新的集合并再次测试。
结果是这样的:
按 StartFetchDateTimeUtc 排序
按_ts排序
关于azure - 为什么按时间戳(字符串)排序的 Azure Cosmos 查询比按 _ts(内置)排序的成本高得多？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45562789/