mongo分頁查詢方式

  閒下來，想了下準備總結下最近在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的緩存，而後經過緩存的內存分頁來解決了這一問題。（想到了一句話：遇到沒法解決的問題那麼就不去解決它^_^）