Cosmos DB跨分区多OR查询RU成本上涨原因咨询

云上老周

2026-8-28

Cosmos DB 多OR条件查询RU成本跳涨问题解答

你的判断完全准确，查询成本跳涨的核心触发原因就是查询从单物理分区本地执行切换为跨多物理分区扇出执行，具体原理和细节如下：

成本变化的底层逻辑

你观察到的两个阶段成本差异，完全对应Cosmos DB两种不同的查询执行路径：

低边际成本阶段（单分区执行）
前3个OR条件匹配的文档恰好落在同一个物理分区时，查询引擎不需要做跨节点调度，直接在单个物理分区内完成索引遍历和结果读取。这一阶段第一个条件需要支付单分区SQL查询的固定基础开销（即你观测到的3RU），后续新增的同分区匹配条件只需要支付索引查找、文档返回的边际成本，所以单条件新增开销仅0.3RU左右。
成本跳涨阶段（跨分区执行）
当第4个及后续OR条件匹配的文档落在其他未被访问的物理分区时，查询自动进入跨分区执行模式：
- 查询引擎首先需要计算查询覆盖的物理分区范围
- 向每个涉及的物理分区单独下发子查询
- 聚合所有子查询结果后返回客户端
  每一个新被命中的物理分区，都会产生一次独立的单分区查询基础开销（约3RU），这就是你观测到第4、第5个条件直接带来3RU成本上涨的原因。
  后续新增OR条件的成本在1.5~3RU区间波动也符合这个逻辑：如果新增条件对应的文档落在本次查询已经命中过的物理分区，就不需要支付新的分区调度基础开销，仅产生同分区边际成本，涨幅就会低于3RU；如果新增条件落在未被访问过的新物理分区，就会再次产生接近3RU的基础开销。

你测试中使用的多OR查询写法参考如下：

SELECT * FROM c
WHERE c.id = 'a'
OR c.id = 'b'
OR c.id = 'c'
//... 追加更多OR匹配条件

你当前编写的不带分区键的多OR查询，本质上属于跨分区查询。前几个条件成本低只是测试数据恰好分布在同一分区的巧合，不是查询被优化成了固定的单分区查询。物理分区的分布由Cosmos DB后台托管，会随着数据量增长自动分裂，你无法长期预判哪些文档会落在同一个物理分区，这种低边际成本的状态完全不可持续。
单文档1RU的点读取（point read）是成本最低的读取方式，前提是请求同时携带文档的id和完整分区键。即使所有查询结果都落在同一个分区，SQL查询的固定解析、执行计划生成、索引遍历开销也会让基础成本高于点读。
不要将多OR拼接的SQL查询作为长期成本优化方案，随着数据量增长、物理分区数量增多，这类不带分区键的查询成本会持续非线性上涨，没有稳定的成本预期。

如果你同时知道待读取文档的id和对应分区键，直接使用SDK提供的ReadMany接口或者事务批量读取接口，单文档的读取RU成本可以接近点读的1RU，性能和成本表现远好于拼接OR条件的SQL查询，且不受物理分区分布变化影响。
如果你只能获取到文档id、无法拿到对应分区键，跨分区查询的基础开销无法避免，这类场景建议提前做好RU预算预留，不要试图通过调整OR条件拼接方式压缩成本。

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