根據頁碼pageIndex和分頁大小pageSize進行分頁。
這種分頁方式在web中沒有錯，但是在app分頁中可以應用嗎？
應用流分頁
從性能上看，App上的分頁模式基本是拉起加載更多形式的流分頁。如果後臺界面還是按照Web分頁設計，會有以下問題:
壹、數據重復
B.缺失數據
c、偏移量過大時查詢效率低。
MySQL的limit給分頁帶來了極大的便利，但當數據量較大時，limit的性能急劇下降。
可見傳統的Web分頁界面並不適合App分頁。
壹、光標光標分頁
優勢:
1)，可以避免數據重復/遺漏。
2)、極限性能不會受光標值影響，性能穩定。
缺點:
1)，適合只加時間的簡單排序。
b、按時間片緩存。
不完整的數據只是壹些流行的數據，因為數據變化太快，可以基於時間段生成多個緩存。對於數據，可以按照時間段(5分鐘)生成壹個緩存碎片。
具體流程如下:
時間切片緩存過程
這裏的時間戳值，當1頁上的數據被請求時，時間戳被傳遞給0，服務器檢查時間戳
緩存的鍵是根據時間戳計算的，比如每5分鐘，key = list _ 201605 231700。
應用場景
比如排名靠前的頁面只是壹些熱門文章，排名比較復雜，相對容易改變。
目前話題中的列表是按照點贊數排序的，分頁請求
出現重復數據是因為排序是實時數據，沒有光標，無法感知之前加載的數據。
C.id列表壹次性發送到App。
1.在請求第壹頁數據之前，緩存所有id列表。
2.當請求每個頁面的數據時，只需要引入相關的id列表參數。
這種方法適用於id列表不大(幾百條數據)的業務場景，比如騰訊新聞。