为什么Node.js查询MongoDB深分页越往后越慢该如何解决？-MongoDB-PHP中文网

根本原因是skip()必须从头扫描计数，i/o和内存开销随跳过条数线性增长；应改用基于_id或复合索引的范围查询实现游标分页。

为什么node.js查询mongodb深分页越往后越慢该如何解决？

深分页越往后越慢，根本原因不是数据多，而是 skip() 本身在 MongoDB 里必须从头扫描计数——第 100 页要跳过前 999 条，第 1000 页就得跳过前 9999 条，I/O 和内存开销线性增长。这不是 Node.js 的锅，是查询模式选错了。

为什么 `skip()` 在 Node.js + MongoDB 中必然变慢

MongoDB 驱动调用 collection.find().skip(N).limit(M) 时，服务端不会“定位”到第 N 条，而是：从第一条开始逐条读、逐条计数、丢弃前 N 条，再取 M 条。哪怕加了索引，skip() 仍需遍历索引项并计数，无法跳过物理位置。分片集群下更糟：每个 shard 都得独立执行 skip(N)，再由 mongos 合并结果。返回空结果时，skip() 依然完整执行，纯属浪费资源。

日志里反复出现 MongoWaitQueueFullException 或 Timed out after 5000ms，大概率就是 skip() 卡住连接没释放
db.currentOp() 显示大量 secs_running > 1000 的操作，且 planSummary 是 COLLSCAN 或 IXSCAN 但 totalDocsExamined 远大于 nReturned
用 explain("executionStats") 查，executionTimeMillis 随 skip 值增大而明显上升，说明瓶颈就在跳过阶段

用 `_id` 范围查询替代 `skip()`（最简单可靠）

_id 是 ObjectId 类型，默认有唯一索引，且天然单调递增（含时间戳），只要不手动插入字符串或数字类型的 _id，就能直接用于升序/降序分页。

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

第一页：collection.find({}).sort({ _id: 1 }).limit(20)
取响应中最后一条文档的 _id（记为 lastId）
下一页：collection.find({ _id: { $gt: lastId } }).sort({ _id: 1 }).limit(20)
前端传回的 lastId 是字符串，Node.js 驱动必须转成 ObjectId 实例：new ObjectId(lastId)，否则查不到
Mongoose 场景下，doc._id 是对象，JSON 序列化后变字符串，后端接收后需显式转换，不能直接当条件用

当业务要求按其他字段排序（如 `createdAt`）时怎么办

如果必须按 createdAt 倒序展示，而 _id 顺序与之不一致，单靠 _id 分页会错乱。此时要建复合索引，并组合查询条件：

先建索引：db.posts.createIndex({ createdAt: -1, _id: -1 })（注意字段顺序和方向）
第一页：collection.find({}).sort({ createdAt: -1, _id: -1 }).limit(20)
取最后一条的 { createdAt, _id }（记为 last）
下一页：collection.find({ $or: [ { createdAt: { $lt: last.createdAt } }, { createdAt: last.createdAt, _id: { $lt: last._id } } ] }).sort({ createdAt: -1, _id: -1 }).limit(20)
别用 $gt 混搭 createdAt 和 _id，MongoDB 无法高效利用索引；$or 写法才能让 B-tree 索引真正生效