C#操作Azure Cosmos DB如何高效查询10万级大量文档数据

FeedIterator本身就是Azure Cosmos DB .NET SDK提供的批量查询官方标准实现，不存在性能设计缺陷，你当前3900条记录耗时45秒的表现，完全是配置、查询写法、测试方式不合理导致的，按以下优先级调整即可，优化后10万条量级的拉取性能会有量级提升：

1. 优先修正查询请求配置（改完就能解决90%的慢问题） #

你当前调用GetItemQueryIterator时没有传入自定义请求参数，默认配置存在两个严重拖慢性能的问题：

• 默认MaxItemCount=100：即每次网络往返最多拉取100条记录，3900条需要至少39次跨网络往返，光网络RTT就占了绝大多数耗时
• 默认MaxConcurrency=1：跨分区查询时串行执行，完全没有利用SDK的并行查询能力

修改代码传入自定义请求配置：

// 放在查询初始化前
var queryOptions = new QueryRequestOptions
{
    // 单页拉取条数根据单文档大小调整，不要触发单响应4MB上限，小文档建议设为500-1000
    MaxItemCount = 1000,
    // 开启并行查询，-1代表SDK自动根据分区数管理并行度，跨分区查询提速明显
    MaxConcurrency = -1,
    // 并行查询缓冲区大小，-1为SDK自动管理
    MaxBufferedItemCount = -1
};
// 传入配置初始化迭代器
using (var appsIterator = _container.GetItemQueryIterator<SensorMaster>(query, requestOptions: queryOptions))
{
    // 你的查询逻辑
}

2. 修正查询写法与索引配置 #

• 禁止使用SELECT *：你的网格控件只用到ID、Name、UnitID、Points四个字段，查询时就只返回这四个字段，大幅减少跨网络传输的数据量和RU消耗，示例查询：

  SELECT c.ID, c.Name, c.UnitID, c.Points FROM c
  

• 尽量命中分区键：如果查询带过滤条件，一定要把容器分区键作为过滤条件传入，避免全跨分区扫描；如果是全量拉取场景，提前确认分区键设计无热点，数据均匀分布在所有分区上。
• 检查索引配置：查询用到的过滤字段、排序字段必须配置对应索引，无索引的全表扫描在10万条量级下性能会下降一个数量级。

3. 适配分页网格场景，不要一次性拉全量数据 #

你要实现带分页的网格控件，完全没必要一次性把10万条数据全部拉到客户端内存：

• 用FeedIterator返回的ContinuationToken实现服务端分页：每次用户触发翻页时，传入上一页留存的延续令牌，只拉取当前页需要的条数（如20/50/100条），首屏加载速度可以从几十秒压缩到几十毫秒。
• 移除测试代码里的非必要IO：你当前逐行打印控制台记录的操作是同步阻塞的，控制台IO本身性能极差，这部分至少占了你当前测试耗时的30%，做性能测试时请单独统计纯数据拉取耗时，不要混入控制台打印、日志写入等其他操作的耗时。

4. 基础环境检查 #

• 确认使用最新稳定版的V3系列Cosmos DB .NET SDK，旧版本存在并行查询相关的已知性能bug。
• CosmosClient请使用全局单例模式初始化，该类是线程安全的，每次查询新建客户端会产生额外的连接初始化、握手开销。
• 性能测试请放在和Cosmos DB同区域的Azure环境内测试，本地公网环境到Cosmos DB的网络延迟是同区域内网的几十上百倍，测试结果不具备参考性。

按上述配置调整后，同区域内网环境下拉取10万条小体积文档的纯耗时通常在2-5秒区间；如果改用服务端分页实现网格，单页查询的耗时基本可以稳定在100ms以内。

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