我们使用ORDER BY ASC获取数据，但不是通过DESC删除

我们得到了多个奇怪的场景。我们使用ORDER BY ASC获取数据，但不是通过DESC删除

例如：

一）我们无法通过_TS订购：空结果

SELECT * FROM data ORDER BY data._ts DESC

b）我们可以ORDER BY ASC和我们得到的成绩（超过> 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 where udf.TEST（rc，“AS”）= RESULTS SELECT * FROM数据r其中udf.TEST（rc，“健康”）=零结果（但由其他字段我可以找到该值）

ks很多！

来源

2015-10-13 jamesjara

请通过http://stackoverflow.com/help/how-to-ask。它应该可以帮助你更好地解决你的问题。更好的框架问题通常会吸引更多的答案。 –

现在回答你的问题：当你收回结果时，你是否检查延续标记？您正在查询的集合是否启用了索引功能？ –

请为UDF问题创建一个单独的问题。 –

jamesjara我离线同步...张贴在这里我们讨论了其他人的利益:)

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

有多久查询范围将在DocumentDB上执行。这些限制包括查询的资源消耗（您可以将这一点与配置的RU/sec * 5秒的数量+未公开的缓冲区进行比较），响应大小（1mb）和超时（5秒）。

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

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

2）ORDER BY和索引策略

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

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

建议的索引策略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子句中包含其他过滤器，以减少要扫描的文档数量。

来源

2015-10-17 05:03:01

我们使用ORDER BY ASC获取数据，但不是通过DESC删除

回答

相关问题