limit分頁通過sql的limit和offset子句實現，適用于中小型數據集。1.每頁條數（page_size）與當前頁碼（page_number）決定offset值，offset=(page_number-1)*page_size；2.性能問題出現在offset值過大時，數據庫需掃描大量記錄再丟棄；3.解決辦法包括避免深度分頁、使用游標分頁、添加合適索引；4.實際開發中建議封裝分頁函數或使用orm內置方法，并在api設計中合理限制參數。
分頁功能是幾乎所有涉及數據展示的系統中都繞不開的一個基礎模塊，尤其在 Web 應用、API 接口和后臺管理系統中非常常見。實現分頁的關鍵在于如何高效地從數據庫中取出指定范圍的數據，而 LIMIT 分頁算法就是其中最常用的一種方式。
什么是 LIMIT 分頁？
簡單來說，LIMIT 分頁指的是使用 SQL 中的 LIMIT 和 OFFSET 子句來控制查詢返回的記錄數量與起始位置。例如：
SELECT * FROM users ORDER BY id DESC LIMIT 10 OFFSET 20;
這條語句表示：按 id 降序排列用戶表，跳過前 20 條記錄，取接下來的 10 條。
這非常適合用于實現“第一頁、第二頁……”這樣的分頁邏輯，但它的性能表現和適用場景需要特別注意。
如何計算頁碼和偏移量？
要正確使用 LIMIT 分頁，首先要理解兩個關鍵參數：
- 每頁條數（page_size）：你希望每頁顯示多少條數據。
- 當前頁碼（page_number）：用戶正在看的是第幾頁。
它們之間的關系是：
offset = (page_number - 1) * page_size limit = page_size
舉個例子，如果每頁顯示 10 條數據，想獲取第 3 頁的內容：
offset = (3 - 1) * 10 = 20
所以 SQL 就會是：
SELECT * FROM table LIMIT 10 OFFSET 20;
這種方式適用于大多數中小型數據集，但在大數據量或高并發下可能會出現性能問題。
LIMIT 分頁的性能問題
雖然 LIMIT + OFFSET 使用起來簡單直接，但它并不是萬能的。主要問題出現在當 offset 值很大時，比如：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 100000;
這個時候數據庫仍然需要掃描前 100000 條記錄，再丟棄掉，只返回最后 10 條。這會導致查詢效率下降，尤其是在沒有合適索引的情況下。
解決辦法有幾個方向：
- 避免深度分頁：比如限制只能翻到前幾十頁，或者提供搜索/篩選代替無休止翻頁。
- 使用基于游標的分頁（Cursor-based Pagination）：通過上一頁最后一條記錄的唯一標識（如 ID 或時間戳）來定位下一頁起點，避免使用 OFFSET。
- 添加合適的索引：確保排序字段有索引，這樣數據庫可以快速定位起始點。
實際開發中的建議
在實際開發中，我們通常會封裝一個通用的分頁函數，接受 page_number 和 page_size 作為參數，然后自動計算 offset 并生成對應的 SQL 查詢。
以下是一個簡單的 python 示例：
def paginate(page_number, page_size): offset = (page_number - 1) * page_size return f"LIMIT {page_size} OFFSET {offset}"
如果是使用 ORM（如 django、SQLAlchemy），一般都有內置的分頁方法，比如 Django 的 Paginator，使用起來更方便也更安全。
另外，在構建 API 接口時，推薦將分頁參數設計為可選，默認值合理，比如 page=1&size=20，并且對最大 size 做限制，防止惡意請求拖垮數據庫。
總結
基本上就這些。LIMIT 分頁的核心在于理解 offset 和 limit 的關系，以及它在不同數據規模下的表現。雖然它不是最高效的分頁方式，但在絕大多數情況下已經足夠好用了。只要注意不要過度依賴 deep pagination，就能很好地滿足業務需求。
