Azure CosmosDB MongoAPI：跳过300条数据后游标失效问题

嘿，我之前帮同事排查过几乎一模一样的问题——从MLab迁到CosmosDB MongoAPI后，大skip分页就报“cursor does not exist, was killed or timed out”。这个坑主要是CosmosDB的游标机制和skip本身的低效性导致的，给你几个实用的解决思路：

为什么会出现这个错误？ #

• CosmosDB的MongoAPI游标有内存和超时限制：当你用skip(N)且N很大时，数据库需要从头扫描N条文档才能定位到起始位置，这个过程会让游标长时间占用资源，很容易触发系统的游标回收机制（要么超时，要么内存超限被杀死）。
• MLab（也就是老MongoDB）对游标的宽容度更高，而CosmosDB作为云托管服务，资源管控更严格，所以之前能用的skip/take在这儿就失效了。

解决方案（按优先级排序） #

1. 用基于唯一索引的键分页替代skip/take（强烈推荐） #

这是CosmosDB官方推荐的分页方案，完全绕开skip的低效问题，也不会触发游标超时。核心思路是用一个有唯一索引的字段（比如_id、游戏ID等）来标记分页的起始位置，每次查询都从这个位置往后取。

举个代码例子：

// 第一页：获取前250条，记录最后一条的_id
SteamGameModel.find()
  .sort({ _id: 1 }) // 按唯一字段排序
  .limit(250)
  .exec((err, results) => {
    if (err) { /* 错误处理 */ }
    const lastDocumentId = results[results.length - 1]?._id;
    // 把lastDocumentId存在前端或缓存里，用于下一页查询
  });

// 后续页面：从lastDocumentId之后取250条
SteamGameModel.find({ _id: { $gt: lastDocumentId } })
  .sort({ _id: 1 })
  .limit(250)
  .exec((err, results) => {
    if (err) { /* 错误处理 */ }
    // 更新lastDocumentId为当前页最后一条的_id
  });

如果你的排序字段不是_id，只要给这个字段创建唯一索引就行，比如游戏的steamId，这样查询效率同样很高。

2. 临时调整游标超时设置（不推荐用于大数据集） #

如果你暂时没法改分页逻辑，可以尝试给游标设置不超时，但用完一定要手动关闭，不然会浪费CosmosDB的资源：

SteamGameModel.find()
  .skip(300)
  .limit(250)
  .cursor({ noCursorTimeout: true }) // 禁用游标超时
  .exec((err, cursor) => {
    if (err) { /* 错误处理 */ }
    cursor.toArray((err, results) => {
      // 处理查询结果
      cursor.close(); // 必须手动关闭游标！
    });
  });

注意：这个方法只是应急用，大skip带来的性能问题依然存在，而且如果游标没关闭，会一直占用CosmosDB的资源，可能导致其他问题。

3. 检查索引和RU配置 #

• 确保你的查询用到的排序字段有索引：如果没有索引，CosmosDB会做全表扫描，速度慢到爆炸，游标肯定会超时。可以用db.SteamGameModel.createIndex({ 你的排序字段: 1 })创建索引。
• 临时调高RU（请求单位）：如果你的集合RU设置得太低，查询速度慢，游标也容易超时。可以在Azure控制台临时调高RU，看看是否缓解，但长期还是要靠优化查询来解决。

总结 #

别再死磕skip/take了，CosmosDB对大skip的场景天生不友好。换成基于唯一键的分页，不仅解决游标超时问题，查询性能还能提升一大截，这才是长期的解决方案。

内容的提问来源于stack exchange，提问作者Eat at Joes