下面這些話，是在我職業生涯的幾個專案中，經常喃喃的自言自語抱怨的事。
不過，與我偶爾不得不發問「為什麼這個api沒有分頁」的不滿相比，這件事上的不滿是什麼呢？讓我從無伺服器架構的混亂工作中抽出一點空來談談分頁。
通俗的講，我見過兩種常見型別的分頁：
我經常見到的乙個錯誤的做法是，要求呼叫者提供乙個"key"來用於結果集的排序，例如按時間戳(timestamp)或者按字母順序來排序，這樣就產生了乙個「抽象洩漏」——呼叫者必需了解伺服器端的底層機制才能使用分頁。
dynamodb資料庫的查詢api就是這樣乙個例子。為了將查詢的結果集分頁，呼叫者必須在一系列的請求中提供exclusivestartkey，伺服器也要在響應中包含lastevaluatedkey。
就其本身而言，這沒什麼大不了的。但是，不幸的是，它經常會產生成一些連鎖反應，那就是這樣鼓勵應用程式的開發人員在進行應用程式開發時，將底層的實現細節暴露在分頁資訊中；下圖這種情況中，客戶端就需要負責跟蹤相應的資訊了。
恭喜你，你的資料庫用來支援分頁的底層機制現在已經全部洩漏給前端了！
另一種我常見的現象是，你必須一次又一次的把相同的請求引數傳送給分頁的api，例如:
當偶爾來這樣做時，我不會把它當作乙個錯誤來看待，但是這樣缺乏設計的機制讓我很煩惱。在我遇到的所有分頁api中，預期的行為始終是獲取查詢的下一組結果，而不是中途可以做其他查詢。這樣做並不合理，實際上都不把這樣的機制叫做分頁，更應該稱其為導航！合理的做法應該是從之前接收的頁面更改分頁的方向。當我們在本文中進一步討論雙向分頁時，將對此進行更詳盡的介紹。
對於單向分頁，我首選的做法是使用簡單的cursor。這裡重要的乙個點是要使cursor變的無意義。
乙個簡單的做法是這樣的：
用base64將json字串編碼
將base64 blob作為cursor返回
這是肯定的，所以你可以選擇先把json進行加密。你也可以選擇不把dynamodb請求作為分頁基礎。
你是否注意到了，在圖1和圖2的例子中，客戶端僅在後續請求中傳送cursor？這是設計使然。
我之前提到過，客戶端已經告訴我們請求是第一次請求，分頁機制只在後續的請求中提供分頁資訊。對於我來說，這意味著分頁機制不應該包含任何其他行為，除了上一次請求的cursor。反過來說，這意味著我們需要在curor中捕獲取原始查詢條件，以便我們構造資料庫查詢語句。或者我們在cursor中獲取實際資料庫請求，這似乎又是乙個簡單而實用的解決方案。
使用雙向分頁時，你需要能夠及時向前(將新的內容新增到時間線中)和向後(獲取舊的內容)進行分頁。因此簡單的字串cursor已經不能滿足需求，我們需要兩個cursor，每個方向使用乙個例如：
好的，讓我們再執行另乙個例子，這次我們按時間線向前翻頁。
現在，讓我們回到之前提過的分頁過程中偶爾需要改變方向的問題。
這意味著，在某個時間點，隨著使用者不斷滾動瀏覽舊推文，客戶端將需要開始刪除已獲取的資料，否則可以會將記憶體耗盡。也就是說，當用記向後舉動檢視推文時，客戶端將需要重新獲取已刪除的資料，從而反轉分頁的原始方向。
這就是我分享的實現單向和雙向分頁的簡單有效的方法，希望它對你有用！
做乙個分頁顯示
關鍵就是用到了sql語句中的limit來限定顯示的記錄從幾到幾。我們需要乙個記錄當前頁的變數 page，還需要總共的記錄數 num 對於 page如果沒有我們就讓它 0，如果有 0就讓它也 0，如果超過了總的頁數就讓他 總的頁數。execc select count from tablename r...
C 乙個顯示分頁頁碼類
在asp.net開發中，常用到顯示分頁頁碼程式，以下是本人寫的乙個類，還未完善，但已可使用，在顯示時當前頁碼會自動據中。並可自定義分類鏈結 using system namespace bookshopcn.service public static string nextpage set publ...
Ext本地資料在Grid中分頁顯示，隱藏指定字段
在已經從後台取得資料data後者前台資料量很大的data時，需要在前台進行分頁顯示var data 已經取得的資料 var fields grid的store的fieldsvar hearder grid的columns屬性 ext.define mygrid 定義資料源 var userstore...