現有方法：

?

???????? 開始時間 [@start_dt ]?? 結束時間 [@end_dt ]

???????? 其它條件 [????? ]

查詢數據總量：[XXXX]

?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

?

缺點：

如果有1000 數據，每頁顯示50條，就要顯示 20個頁連接。

查詢需要先查詢一個數據總量：

db.coll_name.find({date:{$gt:@start_dt,$lte:@end_dt}}).count()

再查詢明細數據：

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).skip(@pageno-1).limit(50)

?

???????? 當查看頁數越來越大時，skip(@pageno-1) 越大，性能越差。

?

?

優化方法：1 （以前提出過）

?

為了減少無效的查詢數據返回，應用頁面中，@start_dt, @end_dt兩個值默認值范圍為1周，或是半個月，減少一次的查詢量。

這個修改，只是在不用修改頁面布局，修改簡單。

以前在沒有默認值的情況下，用戶一選就是一個月，幾個月的情況，后面的查詢等待就幾十秒。。。

更惡心的是每個頁面默認了一個月的查詢范圍，頁面一打開就自動查詢跑結果。弄得頁面打開特別慢，用戶體驗很不好。

（打開頁面不自動查詢，讓用戶選擇要查詢的范圍，再點擊再查詢，相對就好了不少）

?

優化方法： 2

???????? 頁面不顯示所有數據的頁面連接,也不顯示查詢數據的總量，查詢時只查詢 每頁數量 50 +1

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).limit(51)

如果有51條記錄，

頁面顯示表格 下方 顯示 [下一頁]。點擊下一頁翻看后面數據

?

?

查詢數據總量：[XXXX]

?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?

[下一頁]

優點：返回數據量小

缺點：

點擊 [下一頁] 后，如果能用精確定位到某一條記錄，比如：

db.coll_name.find({date:{$gt: @start_dt,$lte: @end_dt},_id:{$gte:@no_51_id}}).limit(51)

_id 大于等于 剛才查詢的第51條記錄的_id 值。

?

如果不能精確定位到某一行，比如只能用時間字段值 { date :{$gte: @no_51_date}}，可能會有不準確的問題。

?

?

優化方法： 3

?

???????? 這個方法可以說是上面兩種的折中。第一次只查詢201條記錄

db.coll_name.find({date:{$gt:@start_dt,$lte: @end_dt}}).limit(201)

?

???????? 如果返回總數小于這個數，那么顯示頁下方不顯示 [更多]，如果有201條，顯示

?

本次查詢數據總量：[200]

?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?
?	?	?	?	?	?

?

1 ?2 ?3 ?4 ?更多

?

這個方法很巧妙的告訴用戶,一次只查了201條記錄，需要更多，還可以查看。

同時返回數據量也減少到了201

第二次查詢如下：

db.coll_name.find({date:{$gt: @start_dt,$lte: @end_dt}}).skip(200).limit(201)

只需要記錄一個變量值： （點擊了幾次[更多]，用來記錄要skip 多少數據。其實用戶不會一直翻頁，翻更多的頁，還不如減小查詢范圍）

?

優點：用戶體驗好，對現有的修改也不大，返回數據量也小???????

缺點：但如果翻頁越來越多，性能還是會變差。

?

?

?

總結

以上是生活随笔為你收集整理的数据查询分页显示的优化方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。