Related Blogs 
This topic created in 2588 days ago, the information mentioned may be changed or developed.
我的 mongo 中有 800 万条数据大概 13 个 G
我的一条查询大概是这样
查询这个人的数据分页
db.events.find({"actor.login": 'name'}).srt({"created_at": -1}).skip(200).limit(20)
一条查询要好几分钟。。
小前端不太会优化，求帮助
 | 1 fox1955 Apr 9, 2019 加个索引啊老铁 |
 | 2 EPr2hh6LADQWqRVH Apr 9, 2019 via Android 如果你就想要结果而不想知道为什么的话，把 created_at 换成_id 目测能够好得多了 |
 | 3 brickyang Apr 9, 2019 via iPhone  1 skip 太多会影响性能。分页最好是每次查询的最后一条记录的 _id，下一批分页的查询用 { $gt/$lt: _id } 配合 limit。 |
| 可能你这数据集还是太稀疏了， 两个方案，一个是加普通的复合索引，created_at 和 actor.login，就按这个顺序 另一个，专门索引，索引项 created_at，选项填一个 partialFilterExpression，就是你 actor.login 的查询条件，再给索引专门起一个名字 你这个情景，我感觉应该第二个方案可能更合适 |
 | 8 rrfeng Apr 9, 2019 加个索引就行 {actor.login:1, created_at: -1} |
 | 9 menyakun Apr 9, 2019 事实上 skip 还是会要从第 1 个遍历到第 200 个，但你这个查询 skip 的数目不是很大，应该不是这个问题。一般来说 sort 肯定是比较慢的，还特别吃内存，既然 sort 的字段是 created_at，那么用_id 也行 |
 | 10 version Apr 9, 2019 应该是是你单个 doc 文件太大了. mongodb 再分页时候会把整个 doc 都缓存放内存..这样容易爆.. 你可以分页查询只 返回_id 和 再单个主键去查询.这样会快点. 这种也适合分页超过 第 20 万以上的时候.. |
 | 11 ScottAlone Apr 22, 2019 @brickyang #3 如果是不是下一页，是下 N 页的话有什么办法吗... |
Select Language