【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
闲下来，想了下准备总结下最近在mongo查询上所遇到的一些问题，我在这里罗列一下。
1.mongo使用shell的find查询：
查询long型字段时，需要在查询条件里使用NumberLong("xxxx")包裹起来，这样才是精确查找，不然查找到的数据是不一致
2.mongo添加一个字段：
为mongo的每一条记录都添加一个字段时，使用uodate时，加入插入的字段默认值是int型的，那么直接填写值的话，插入后会变成double型的数据，后面自动添加“.0,必须用NumberInt(xx)来包裹；因为mongo是基于bason格式的，而bason里面是有int类型，而mongo的shell是基于json格式的，json格式中只有number类型，所以才使用int或者long型必须用number来包裹；
3.mongo分页方式讨论
①一般的分页使用skip，limit来结合，这个方式实现起来很简单，并且前期问题也不打，但是当数据量上去以后就会越来越卡，我测试过10W数据量，当一次查询发起的时候会卡很久，建议小数据量时使用；
②第二种方式是基于瀑布流形式的下拉分页，其通过排序某个唯一字段，然后获取上一条记录大这个字段通过对比获取上一页或者下一页的数据，这个方式是我们现在业务中普遍使用的，对于大数据量的情况下性能也很不错，但是其中有2各地方需要注意，第一点：在翻页是必须先排序，然后在获取，然后如果可以上下翻页的话，排序方式也需要根据相应的转换，不然获取的数据会错乱，具体需要根据自己实际测试来改动；第二点：排序的字段必须是唯一，这个条件很苛刻，所以一般情况下我们都是用创建时间或者是mongo自带的主键来排序，当然当高并发情况下创建时间也是可能存在重复，那么当这个唯一属性存在重复的时候，在翻页时我们将丢失某一条重复的数据（这个问题不知道如何解决）。我的业务场景中就有这么一个地方存在重复的，但是我在service那边做了redis的缓存，然后通过缓存的内存分页来解决了这一问题。（想到了一句话：遇到无法解决的问题那么就不去解决它^_^）
来源：oschina
链接：https://my.oschina.net/u/2416235/blog/1615052