mongodb大offset分页性能差因skip需线性扫描丢弃前n条，索引仅加速查找排序无法跳过计数；应建复合索引（如{createdat:-1,_id:-1}）并用游标替代skip，通过$or条件精确分页。
当MongoDB分页请求跳过10万、100万甚至更多文档时，响应时间陡增、CPU飙升、接口超时频发，根本原因是skip必须线性扫描并丢弃前N条——哪怕加了索引也绕不开逐条计数过程。
为什么索引无法拯救大offset的skip
执行db.coll.find({status: "active"}).sort({createdAt: -1}).skip(500000).limit(20)时，MongoDB先用{status: 1, createdAt: -1}索引快速定位所有active文档，再按createdAt倒序排列，最后从头开始数、丢弃前50万条。索引只加速了“找”和“排”，没跳过“数”这一步。
explain("executionStats")会显示totalDocsExamined ≈ 500020，nReturned = 20——这意味着99.996%的扫描结果被当场丢弃。
如果排序字段没索引，还会触发inMemorySort，内存占用暴增，mongod可能直接OOM。
必须建立的复合索引结构
方法一：单字段时间排序（最简场景）
适用：仅按createdAt倒序，且业务允许同一秒内少量乱序
执行：db.coll.createIndex({createdAt: -1})
注意：【该索引必须严格匹配sort顺序，否则仍会全表扫描】
方法二：防重复时间戳的复合索引（推荐生产使用）
原因：用户批量导入、服务端时钟回拨、高并发写入都可能导致createdAt重复，单靠它做游标会漏或重数据
执行：db.coll.createIndex({createdAt: -1, _id: -1})
这个组合确保每条记录在索引中位置唯一，且天然支持范围查询下推
方法三：带业务过滤条件的覆盖索引
适用：分页同时带多个等值条件，如{type: "order", status: "paid"}
执行：db.coll.createIndex({type: 1, status: 1, createdAt: -1, _id: -1})
关键点：等值字段放前面，范围/排序字段放后面；_id必须收尾，兜底去重
用游标替代skip的实操步骤
第一步：获取第一页数据并提取游标锚点
运行db.coll.find({type: "order", status: "paid"}).sort({createdAt: -1, _id: -1}).limit(30)，取返回数组最后一项的{createdAt, _id}值，记为last。
第二步：构造下一页查询条件
不能只写{createdAt: {$lt: last.createdAt}}——这会跳过同秒内_id更大的所有记录。
必须用$or表达式精确覆盖两种情况：db.coll.find({ $or: [ { createdAt: { $lt: last.createdAt } }, { createdAt: last.createdAt, _id: { $lt: last._id } } ] }).sort({createdAt: -1, _id: -1}).limit(30)
第三步：验证执行计划是否真正生效
在查询末尾追加.explain("executionStats")，确认：
• executionStages.stage === "IXSCAN"（不是COLLSCAN或SORT）
• totalDocsExamined接近nReturned（例如取30条，只扫描35条）
• indexName与你创建的复合索引名完全一致
第四步：Node.js驱动中正确传递ObjectId
前端传来的last._id是十六进制字符串，MongoDB原生驱动需显式转换：
const { ObjectId } = require("mongodb");<br>const cursorId = new ObjectId(last._id);
若用Mongoose，注意
doc._id是ObjectId实例，但JSON.stringify(doc)后丢失类型，后端接收必须重铸
