因新增數據產生分頁數據重復的一個解決方案
數據分頁加載是一種歷史悠久的交互優化方式，很好的解決了大量數據一次性加載速度慢的問題。但如果只是簡單地使用page number和page size計算offset進行分頁的話，老司機們都知道會有一個非常討厭的BUG。。。
當你的list是按時間倒序排序的時候，這個BUG就會時不時地出現。這個bug就是list中會出現一些奇怪的重復數據，確切地說是上一頁最后一條或幾條數據會再次出現在下一頁的前面一條或幾條。當然，你如果按時間順序排序的話，這個bug是不存在的。
根據這個bug的特征，我們可以推斷出導致它產生的原因就是數據集發生了變化。為什么會產生變化呢，因為新增了數據。。。倒序排序時，新增加的數據在棧頂。根據頁碼和每頁行數計算出來的offset，就是棧頂到目標位置的距離。現在棧頂升高了，而距離沒變，那么取出來的數據自然就不是原先所期望的數據，而是上次已經取過的數據了。這里借用棧的概念，只是為了更形象地說明問題，實際查詢數據的時候，並不需要搬運漢諾塔，解決問題的方案，也和棧沒有半毛錢關系。
好吧，現在我們已經明了問題的原因，那么該如何去解決這個問題？
我同事提供了一個加入時間參數或序列號的方法，查詢時增加一個時間或序列號作為條件，使得動態增加的數據不會再出現在結果數據集中。我百度了一下，發現這個方法還挺流行的。只是這個方案並不能完全解決問題。當查詢時產生了多條新的數據，而這些數據只有部分進入結果數據集的話，下次查詢得到的結果數據集就會全部的上次新增數據而非部分。也就是說結果數據集在這種巧合下，還是變大了。。。當然，這種巧合非常罕見，但這個方法最大的問題並不是上面所說的問題，而是他需要依賴一些數據。如果你沒有記錄的創建時間或者自增ID之類可供利用的數據的話。。。只能撫額嘆息了。
有沒有不依賴數據的方法呢？讓我們先回到問題本身：結果數據集變大導致分頁偏移量指向了錯誤的位置！那么解決這個問題最直接的方法應該是修正這個分頁偏移量，使之指向正確的位置就好了。接下來，我們就來修正這個應該同步變大的偏移量。當然，這也僅僅適用於新增數據在棧頂的情況，至於新增數據不在棧頂、或者結果集變小導致的問題將在下一篇文章中探討。
事實上，修正偏移量的方法簡單地令人發指！就是在基於頁碼和每頁行數計算出來的偏移量的基礎上，加上新增加數據的數量就可以了。。。而新增加了多少數據，只需要調用分頁查詢接口的時候，傳入上次返回的總數，然后把查詢得到的count減去傳入的count就可以簡單地獲得。
簡單到簡直難以置信，對吧？如果你不能抓住問題的根源，流於問題的表象所提出的解決方案一般來說都是復雜的，而且並不能完全解決問題。但只要找到問題的根源，解決方案就會變得異常簡單，而且可以一勞永逸地解決此類問題。