Java操作MongoDB的最佳分页方法及skip+limit性能疑问

嘿，这个问题问得特别戳中MongoDB分页的常见困惑点，我来给你拆解明白：

不管是用Mongo Shell还是Java驱动，skip和limit都是MongoDB服务器端执行的指令，完全不会出现“先获取所有200万条记录再在客户端做跳过和截取”的情况。

具体来说，当你执行collection.find().skip(n).limit(n)时：

• MongoDB服务器会直接在存储层定位到跳过n条后的起始位置，然后只取出n条记录返回给Java驱动
• Java驱动只会接收这n条结果，不会接触到其他199万+条数据

Java驱动本质就是个“请求翻译官”：它把你写的链式调用（find()/skip()/limit()）转换成MongoDB能识别的查询协议，发送给服务器；等服务器处理完分页逻辑，再把少量结果集传回给驱动，驱动再转换成Java对象给你用。

全程驱动都不会做任何大数据量的本地处理，所有核心逻辑都在MongoDB服务器端完成。

1. 混淆了客户端/服务器端的职责边界：你误以为skip/limit是客户端对全量数据的二次加工，但实际上这些都是服务器端的查询参数，和使用什么语言的驱动无关。
2. 没意识到大skip值的性能坑：虽然不会拉全量数据，但如果n特别大（比如要跳过199万条取第200万条开始的10条），服务器还是需要遍历前面199万条文档才能找到起始位置，这时候会触发全表扫描（如果没有合适索引的话），性能会急剧下降——这才是这种分页方式的真正问题，不是客户端的锅。

如果要处理百万级别的分页，别再用skip()+limit()了，推荐用基于有序唯一字段的游标式分页，比如用_id或者带索引的时间戳字段：

// 第一页：按_id升序取100条
FindIterable<Document> firstPage = collection.find()
    .sort(Sorts.ascending("_id"))
    .limit(100);

// 第二页：用上一页最后一条的_id作为起始条件，继续取100条
Document lastDocOfFirstPage = ...; // 第一页的最后一条文档
FindIterable<Document> secondPage = collection.find(
        Filters.gt("_id", lastDocOfFirstPage.getObjectId("_id"))
    )
    .sort(Sorts.ascending("_id"))
    .limit(100);

这种方式利用索引直接定位起始位置，不管分多少页，性能都能保持稳定，不会出现大skip的性能问题。

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