CosmosDB SQL查询带/不带ORDER BY返回结果数量不一致问题咨询

这绝对不是API的重大缺陷，而是Cosmos DB SQL API在跨分区查询+全局排序场景下的默认设计行为，我来给你拆解清楚：

核心原因：跨分区排序的默认数据拉取限制 #

当你启用EnableCrossPartitionQuery = true并且查询包含ORDER BY时，Cosmos DB SDK的处理逻辑是这样的：

• SDK会将查询分发到所有相关的分区上；
• 每个分区默认只会返回前1000条符合条件的数据（这个数量由FeedOptions.MaxItemCount控制，默认值是1000）；
• 所有分区的结果返回后，SDK在客户端内存中进行全局排序，最终返回合并后的结果。

这就导致你看到的差异：带ORDER BY时只拿到了合并排序后的1000条数据，而去掉ORDER BY时，跨分区查询会并行拉取所有分区的全量符合条件的数据，因此能拿到完整的6000条。

如何获取全量排序后的结果？ #

要拿到所有符合条件且排序完成的数据，你需要使用分页查询，通过ContinuationToken分批获取数据，而不是直接用AsEnumerable()。具体代码调整如下：

// 改用AsDocumentQuery()来支持分页逻辑
var query = client.CreateDocumentQuery<dynamic>(
    collection, 
    "SELECT c.Name, c.Grade FROM c WHERE c.Grade > 10 AND c.Category = 'A' ORDER BY c.Name", 
    new FeedOptions { EnableCrossPartitionQuery = true }
).AsDocumentQuery();

List<dynamic> fullResults = new List<dynamic>();
while (query.HasMoreResults)
{
    // 异步分批获取结果（同步场景可改用ExecuteNext方法）
    var responsePage = await query.ExecuteNextAsync<dynamic>();
    fullResults.AddRange(responsePage);
}

// fullResults中就是所有符合条件并完成全局排序的数据

如果数据量不大，你也可以手动设置MaxItemCount为一个足够大的数值（比如10000），但这种方式不适合超大数据量，容易导致客户端内存压力过大，分页机制才是更稳妥的方案。

为什么会有这个默认限制？ #

这个设计是为了保护客户端内存——跨分区全局排序需要将所有待排序的数据加载到客户端内存中，如果不做默认限制，当数据量极大时，很容易导致客户端内存溢出。通过默认限制+分页机制，开发者可以更灵活地控制数据拉取的节奏。

内容的提问来源于stack exchange，提问作者DeveloperInToronto