Cosmos DB OFFSET LIMIT RU成本与官方文档矛盾的技术问询

你的测试结果和官方文档的差异，问题出在查询的索引优化情况以及文档描述的适用场景，拆解一下原因：

• 你的测试命中了最优索引路径
  如果你的查询是基于带范围索引的字段排序（比如主键id，或者自定义复合索引），Cosmos DB能直接靠索引定位到OFFSET指定的位置，根本不需要扫描、加载那些要跳过的文档。这种情况下，不管OFFSET值多大，RU消耗都会保持稳定——数据库只需要找到起始点，再取后面10条数据，和跳过的数量没关系。你测试里的RU波动只是正常的性能误差，不是文档说的随偏移量上升的趋势。

• 官方文档的描述针对无索引/低效索引场景
  文档里说OFFSET LIMIT效率低、RU随偏移量上升，是指没有合适索引支持排序或过滤的情况。比如你要是用一个没建索引的字段排序，再用OFFSET，Cosmos DB就得扫描前面所有文档来跳过，偏移量越大，扫的文档越多，RU自然就飙升。这种坑才是文档要提醒你避开的场景。

• continuation tokens依然是分页首选的原因
  就算OFFSET LIMIT在索引拉满的场景下RU稳定，continuation tokens还是有不可替代的优势：

  • 不会出现数据一致性问题：分页过程中如果集合有数据增删改，OFFSET很可能导致前后页重复或者漏数据；而continuation tokens是跟着上次查询的物理位置续查，能保证结果连贯一致。
  • 跨分区场景更高效：如果数据分布在多个物理分区，OFFSET得协调所有分区的结果来算偏移量，而continuation tokens会跟踪每个分区的查询断点，后续直接从各分区的断点继续，性能更稳。
  • 超大偏移量的性能优势：哪怕有索引，OFFSET值极大时，数据库定位偏移位置的开销还是会慢慢增加；但continuation tokens每次都是轻量续查，性能不会随分页深度下降。

说白了，你的测试是OFFSET LIMIT的最优情况，而官方文档是在提醒开发者注意低效场景的问题，两者并不矛盾——但continuation tokens的适配性和稳定性，依然是Cosmos DB分页的首选方案。

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