前端分頁查詢的另一種想法（基於游標和每頁條目）

不知道你們有沒有聽說過這樣的分頁需求：

將每個使用者的查詢每次的查詢情況快取起來，然後將它查第二頁時，直接從快取中獲取，除非其查詢第一頁。

這樣的理由在於，後台的資料在不斷地增加中，你現在看到的第一頁，或許在下乙個時刻，就發生了變化。而如果此時你要看第二頁，是需要基於上一次查詢的第二頁，而不是重新排序的第二頁，因為此時，有可能會出現之前看到的第一頁資料，或者比之前第一頁的資料更靠前（因資料增加得很快，重新排序在上一次第一頁前面）。

基於此，當時的其它人說，之前就是將資料快取起來，有個時間，如果查了，就給顯示，不查過期失效，並且，這個快取是針對session或記憶體做的。

我對於此很排斥的，因為這個設計真的很爛。爛到如果客戶的資料比較多，可能幾個，幾十個客戶就可能把一台機器查崩。當時也只是問了下，並沒有繼續做下去。並且，記憶體資源的極大浪費。

有沒有發現乙個問題，前面的需求中，出現查第二頁時，資料紊亂的情況，是逆序排序的情況下，正序情況下是不可能出現這種情況，除非資料庫條目插入時，是逆序的（相當於，我先插入乙個id = 10，再插入乙個id = 9 ）。

現在重新思考這個問題，發現有其它的方法可以處理該問題。首先先明確幾個前提：

1、我們並不是為了效能，即客戶響應速度而需要將其放在快取

2、我們後台資料增加得或許很快，但是不會出現刪除資料的情況。比如，交易流水

3、顯示的資料，不是以資料庫的插入順序為準的，而是有一定的排序規則

基於此，我們來思考下，有什麼什麼方案，至少優於前者的方案，來實現這個需求。

我們分頁顯示的資料，一般都有乙個排序規則，有可能是主鍵id，也有可能是時間戳……那麼，我們是否可以將本次查詢的最後一條資料的排序規則作為乙個引數來上送，進行查詢。

即，第一次查詢時，走預設查詢邏輯，僅提供查詢條件及查詢條目，後台返回資料及存在的總資料條目。（此時後台執行了兩次資料查詢，一次計數，一次查詢。有些專案將其改為了一次，但是那個執行邏輯就我看，很爛，還不如分開）

非第一次查詢時，提供上一次查詢最後的一條資料的排序游標，及查詢條目。此時後台就會根據這個條件取相應的資料，並且此時後台執行的資料庫查詢邏輯是一次，不存在計數的邏輯了。