mongodb分页查询优化_

看到这里sort条件基本不会有问题，那问题就一定出在了skip加limit上，于是为了验证我的推论，我再去MongoDB后台观察，并调出了资源管理器。再次运行发现，当分页查询很慢时，电脑的内存使用率竟然到了90%多，但是磁盘读写却很低，CPU也没有被利用起来，所以排除了磁盘效率问题，确认是内存使用问题。

那为什么一个简单的查询会导致内存使用率会这么高呢？

原来MongoDB在处理skip limit时，由于指定了skip的数量，所以数据库会进行全表顺序扫描，扫描完你skip的数量后，再按你的limit获取指定的数据集。注意这里有一个全表顺序扫描的过程，如果你的数据量很少，那全表扫描很快，但是如果你的数据量很大，越到后面，每一次的分页查询都需要从第一行数据扫描到你当前要skip的行数。

举个例子，例如你的表数据总量是1000万，你的分页每页数量是1000，那如果你想查出第101个分页的数据时，MongoDB会需要先扫描完前100个分页的数据，也就是100*1000=100万，然后再扫描完的记录起，取你分页的配置（limit）1000条数据。

这时由于全表扫描，会占用大量的内存，同时由于没有索引可用，速度是非常慢的。

找到问题原因，解决方案也就有了：

造成查询速度慢的主要原因是全表扫描没用到索引；那如何让我们每次查询都用到索引呢？

1、由于开始的第一个分页不需要skip数据，所以非常快，当拿到第一个查询分页的结果后，得到他最后一条记录的id；

2、拿到上面的id后，第二次分页查询时，query里添加条件：记录的id大于上一个分页的最后一条记录的id；由于id上面有索引，所以这样能够非常快的定位到需要查询的记录的开始位置，然后再通过limit取出分页数据。

 DBObject queryObject = new BasicDBObject();
 if (null != query && null != query.getQueryObject()) {
 queryObject = query.getQueryObject();
 }
 LinkedHashMap<Object, ObjectId> idCondition = new LinkedHashMap<>();
 idCondition.put("$gt", new ObjectId(lastId));
 queryObject.put("_id", idCondition);
 BasicQuery queryCopy = new BasicQuery(queryObject);
 queryCopy.with(new Sort(new Order(Direction.ASC, "_id")));
 queryCopy.limit(pageSize);

经过上面的修复调整后，再进行试验，发现问题得到了解决，导出速度一直很稳定，CPU疯转，磁盘使用率也得到了充分利用，整个本本呜呜带风。最终几亿数据，半小时内就可以全部导出。

视频加载中...

写在最后，由于这个问题已经有段时间了，没有记录下当时的日志，有些遗憾，不能更好的表述问题，但是基本思路就是上面这些，希望对大家有所帮助，如果您觉得有意义，关注我，后面会不定期还有分享。

本文标签：数据库(97)MongoDB(3)全表扫描(1)分页查询(1)分页(1)