項目當中模擬插入了120W條數據，在同一個文檔當中單純查詢數據的速度還不錯，主要是對查詢的文檔字段添加了索引，但是對查詢結果的前臺分頁確有問題。具體來說是不設置任何查詢條件的時候，會查詢出來將近120W條滿足條件的結果，使用mongodb的limit()和skip() 來取出來 第一頁前20條數據，這樣在後臺的java程序當中只是這20條數據佔用內存。
代碼具體形式類似於用mongodb客戶端執行db.feedbackInfo.find(criteria).skip(0).limit(20) 獲得第一頁0-20條數據db.feedbackInfo.find(criteria).skip(20).limit(20) 獲得第二頁20-40條數據……db.feedbackInfo.find(criteria).skip(N).limit(20) 獲得第二頁N-N+20條數據但問題在於隨着不斷翻頁，skip的值N會越來越大，前臺的反應越來越慢。很直接的一個表現就是在前臺從第一頁直接跳轉進入最後一頁根本反應不過來。對於這個實際問題，原因就是本書這裏所言的skip略過大量結果會帶來性能問題，再根源地說是mongodb還不夠完善，索引本身還比較簡單。具體的這個分頁效率的問題，有兩種思路：第一，等mongodb升級，優化這個skip的執行效率。第二，不用skip()而實現分頁效果。這個思路的基礎就是mongodb本身對於where查詢和limit()的效率還比較不錯，也就是本來分頁的那個查詢用where和limit速度還可以的前提（一般就是需要建立必要的索引）。假如這個前提不成立，那沒法討論。本書接下來具體討論了不使用skip對結果分頁的實現例子，這個本質是對信息系統增加一個查詢中間量——上次查詢的業務數值，在邏輯上承擔起跟skip相對等價的功能。比如說是第一頁查詢是按照一個日期date值查詢，第一次用db.foo.find().sort({"date",-1}).limit(20)而點擊下一頁的時候，事先將上次查詢的date的邊界值給傳遞過去，第二頁查詢的時候就使用新的find條件查詢db.foo.find({"date":{"$gt":latest.date}}); 而後再對查詢結果排序即可這種繞過skip的方式評價：第一，很難比較方便地解決所有的分頁問題，簡單來說 對於使用正則表達式的查詢，根本無法通過記錄邊界條件來實現。第二，不得不多傳遞上次查詢的那個邊界條件，增加了工作量，不夠優雅。第三，只能夠解決一頁一頁往下翻頁的問題，如果我要從第1頁直接跳到100頁，就束手無策