Question

我们遇到了多种奇怪的情况。

例如：

a）我们无法按_ts排序：空结果

SELECT * FROM data ORDER BY data._ts DESC

b）我们可以通过ASC ORDER获得结果（超过＆gt; 100）。但是如果我们ORDER BY DESC我们得到零结果，对我们没有意义:(，

假设c是一个整数，这就是我们看到的行为：

SELECT * FROM data ORDER BY data.c ASC  = RESULTS
SELECT * FROM data ORDER BY data.c DESC = zero results

c）我们有一个UDF要包含的内容，但并不适用于所有情况，JS功能在外部测试，IT正在工作，我们不明白 SELECT * FROM data r其中udf.TEST（r.c，“AS”）=结果 SELECT * FROM data r其中udf.TEST（r.c，“health”）=零结果（但是通过其他字段我可以找到它的值）

非常感谢！

Answer 1

jamesjara和我同步离线...在这里发布我们的讨论给其他人带来的好处：）

1）查询响应限制和续续令牌

查询在DocumentDB上执行的时间有限。这些限制包括查询的资源消耗（您可以将此配置为RU /秒的数量* 5秒+未公开的缓冲区），响应大小（1mb）和超时（5秒）。

如果达到这些限制，则可能会返回部分结果集。查询执行所完成的工作是通过以HTTP响应头中的延续令牌（x-ms-continuation）的形式返回状态来保留的。您可以通过在后续查询中传递延续令牌来恢复查询的执行。客户端SDK通过toList()或toArray()自动分页结果（取决于SDK风格），使此交互变得更容易。

可以在结果中获得空白页面。在查询引擎找到第一个结果之前达到资源消耗限制时（例如，通过集合扫描以在大型数据集中查找少量文档时），可能会发生这种情况。

2）ORDER BY和索引政策

为了在查询中使用ORDER BY或范围比较（<，>等），您应该指定一个包含具有最大精度的Range索引的索引策略（精度= -1）超过用于排序的JSON属性。这允许查询引擎利用索引。

否则，您可以通过指定x-ms-documentdb-query-enable-scan HTTP请求标头并将值设置为true来强制执行扫描。在客户端SDK中，这是通过FeedOptions对象公开的。

ORDER BY的建议索引政策：

{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    {
      "path": "/*",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "Number",
          "precision": -1
        },
        {
          "kind": "Range",
          "dataType": "String",
          "precision": -1
        }
      ]
    },
    {
      "path": "/_ts/?",
      "indexes": [
        {
          "kind": "Range",
          "dataType": "Number",
          "precision": -1
        }
      ]
    }
  ],
  "excludedPaths": []
}

3）UDF和索引

UDF无法利用索引，并将导致扫描。因此，建议在查询WHERE子句中包含其他过滤器，以减少要扫描的文档数量。

我们使用ORDER BY ASC但不是DESC来获取数据

1 个答案: