用_id范围查询替代skip()可解决80%以上慢响应问题，因skip()需线性扫描前N条，而_id天然单调递增且有索引，配合.lean()、精准复合索引和字段投影可实现高效分页。
直接用 _id 范围查询替代 skip()，再配合 .lean() 和精准索引，能解决 80% 以上的慢响应问题。
为什么 skip() 在分页时越来越慢
MongoDB 执行 skip(N) 不是跳转，而是从头开始逐条扫描、计数、丢弃前 N 条——N 越大，I/O 和 CPU 消耗越线性增长。即使有索引，它仍要遍历 N 个索引项，无法跳过物理位置。
- 高偏移量（如
skip(10000)）下，单次查询可能耗时数百毫秒甚至秒级 - 分片集群中，每个 shard 都要独立执行
skip()，再由mongos合并，放大开销 - 返回空结果时，
skip()依然完整执行，纯属浪费资源
用 _id 范围查询实现真·高效分页
_id 是 ObjectId 类型，默认有唯一索引，且天然单调递增（隐含写入时间戳），无需额外排序即可保证顺序稳定。
- 第一页：
collection.find({}).sort({ _id: 1 }).limit(20) - 取响应中最后一条文档的
_id（记为lastId），注意它是字符串；后端接收时必须转成ObjectId实例：new ObjectId(lastId) - 下一页：
collection.find({ _id: { $gt: lastId } }).sort({ _id: 1 }).limit(20) - 删+插操作会重置
_id连续性，务必改用updateOne替代deleteOne + insertOne - 不要 fallback 到
skip()补足不足limit条数——那一步就让整个优化归零
必须同步加固的三个配套点
只换分页方式不够，以下三点不处理，加速效果会被抵消：
-
.lean()必须加在.exec()或await前：Mongoose 返回 POJO，避免Document实例带来的内存和 GC 开销 - 复合索引要覆盖查询条件和排序字段：例如按
createdAt分页，建索引{ createdAt: -1, _id: -1 }，查询条件用{ $or: [ { createdAt: { $lt: last.createdAt } }, { createdAt: last.createdAt, _id: { $lt: last._id } } ] } - 投影只取必要字段：
find({}, { projection: { name: 1, status: 1 } })，减少网络传输和内存占用
容易被忽略的连接与监控盲区
响应慢不一定是查询逻辑问题，也可能是连接或日志配置没跟上：
-
maxPoolSize默认是 5，QPS 超过 1000 时建议设为 30–50，否则请求排队等待连接 - 服务端 profiling 必须开启：
db.setProfilingLevel(1, { slowms: 200 })，Node.js 层监听commandSucceeded事件才有效 -
system.profile是 capped 集合，不支持changeStream，轮询必须带ts索引和游标，间隔 ≥1s，否则轮询本身变慢操作
真正卡住的往往不是 _id 范围怎么写，而是 .lean() 加在了 await 后面、lastId 没转 ObjectId、或者压根没开 profiling 就去查慢日志——这些点一漏，前面所有优化都白做。
