MongoDB游标查询count与skip/limit分页结果是否一致？

首先明确两个基础结论：

• MongoDB普通游标不会固定指向同一批静态查询结果。默认配置下游标不会在查询发起时生成全量结果的快照，而是分批从服务端拉取匹配文档，拉取过程中如果集合发生增删改，后续批次返回的内容可能和初始查询的预期结果存在偏差。
• 带skip、limit的分页场景下，直接复用同一个游标先后执行总数统计和文档列表查询，确实会出现结果不匹配的问题，结合给出的示例代码具体说明：

const builtQuery = { ... };

const myCursor = MyCollection.collection.find(builtQuery);
const totalCount = await myCursor.count();
const docs = await myCursor.skip().limit().toArray();

针对示例代码的具体疑问解答 #

• 关于「两次操作是否属于同一次数据库请求」：
  不属于。find()方法调用时仅会在客户端本地初始化游标对象，不会立刻和MongoDB服务端交互。第一次执行await myCursor.count()时，客户端会单独向服务端发送count命令，基于builtQuery条件统计匹配文档数；后续调用skip()、limit()只是修改本地游标的查询参数，执行await toArray()时会发起第二次独立的find请求，携带分页参数拉取对应范围的文档，两次请求完全独立。

• 关于「如何确认totalCount是匹配条件的准确总数」：
  首先要注意默认cursor.count()的统计逻辑存在偏差：WiredTiger存储引擎下，无强制扫描参数的count会优先读取集合元数据的近似统计值，在频繁增删的集合上误差会非常明显。要拿到count命令执行当下的准确匹配数，调用count时必须传入配置项：myCursor.count({ applySkipLimit: false })，强制命令逐行扫描匹配文档统计，不要走元数据估算。如果查询走指定索引，还可以加上hint参数指定对应索引，减少统计时的性能损耗。
  注意这个准确值仅代表count命令执行瞬间的匹配数，不代表和后续分页查询的结果一致。

• 关于「两次操作间隔数据变更是否会导致数值不符」：
  一定会出现不一致。由于count和分页查询是两次完全独立的请求，默认情况下两者没有任何快照绑定，两次请求的间隔哪怕只有几毫秒，在高并发写入场景下都可能出现数据变动：比如count执行时匹配总数是100，间隔期有5条匹配文档被删除，后续分页查询时实际匹配总数只有95；如果变动刚好落在分页查询的范围内，还可能出现返回的文档数量和limit参数不符、甚至skip值超过当前实际总文档数返回空列表的情况，和之前拿到的totalCount完全无法对应。

一致性场景的实现建议 #

如果业务要求totalCount和返回的docs列表严格匹配，可选择以下方案：

• 强一致需求：将count查询和分页find查询放在同一个多文档事务中执行，事务会提供统一的快照视图，两次查询都基于同一个时间点的数据执行，不会受期间其他写入操作的影响。注意控制事务执行时长，避免长事务带来的锁占用、性能开销问题。
• 弱一致需求：大数据量分页场景下不建议每次查询都统计实时总数，可以接受秒级延迟的场景下用定时任务预计算匹配总数，或者使用countDocuments方法做统计，搭配查询的索引优化减少统计耗时，缩短两次请求的间隔，降低不一致出现的概率。

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