在數據驅動的應用中，分頁是不可或缺的功能。然而，當數據量達到百萬甚至千萬級別時，傳統基于 LIMIT OFFSET 的分頁方式會遭遇嚴重的性能瓶頸，即“深分頁”問題。本文將剖析其根源并提供主流的優化策略。

---

問題根源：LIMIT OFFSET 為何會慢？

我們最常用的分頁查詢語句如下：

-- 查詢第10001頁，每頁10條數據
SELECT * FROM products ORDER BY id LIMIT 10 OFFSET 100000;

這條SQL的執行邏輯并非直接定位到第100,001條記錄。MySQL的實際處理過程是：

1. 從存儲引擎中讀取滿足條件的前 100010 (OFFSET + LIMIT) 條記錄。
2. 在服務層（Server Layer）對這些記錄進行排序。
3. 拋棄前面的 100000 條記錄。
4. 返回最終的 10 條記錄。

OFFSET 值越大，MySQL需要掃描、加載并最終拋棄的行數就越多，這導致了巨大的I/O和CPU資源浪費，是性能下降的直接原因。

---

優化策略

1. 延遲關聯 (Deferred Join)

延遲關聯的核心思想是先通過覆蓋索引快速定位到目標頁的主鍵ID，然后再關聯原表獲取完整的行數據，從而減少對主表數據的掃描。

• 實現方式

  -- 先通過覆蓋索引快速定位ID，再進行關聯
  SELECT p1.*
  FROM products AS p1
  INNER JOIN (-- 子查詢僅在索引上操作，速度很快SELECT id FROM products ORDER BY id LIMIT 10 OFFSET 100000
  ) AS p2 ON p1.id = p2.id;
  

• 優點：保留了跳轉任意頁面的功能，性能相較于原始方法有顯著提升。

• 缺點：SQL語句更復雜；當OFFSET值極大時性能仍會下降。

2. 鍵集分頁 (Keyset Pagination)

鍵集分頁，或稱“書簽”法，是目前性能最優的方案。它摒棄了OFFSET，通過上一頁最后一條記錄的唯一鍵值來定位下一頁的起始位置。

• 實現方式

  假設我們按自增id排序，上一頁返回的最后一條記錄id為100000。

  -- 不使用OFFSET，而是利用上一頁的id進行定位
  SELECT * FROM products
  WHERE id > 100000
  ORDER BY id ASC
  LIMIT 10;
  

• 優點：查詢性能恒定，不受分頁深度影響，速度極快。

• 缺點：無法直接跳轉到指定頁碼，僅適用于“上一頁/下一頁”或無限滾動場景。需要一個唯一且有序的排序列。

3. 業務限制

從產品層面限制用戶能夠訪問的最大頁數（例如100頁）。在多數場景下，用戶很少會瀏覽非常靠后的頁面，引導用戶使用更精確的篩選條件是更有效的方式。

• 優點：實現簡單，從根本上規避了技術難題。
• 缺點：犧牲了部分功能，不適用于必須允許訪問所有數據的場景。

---

總結

策略	優點	缺點	適用場景
延遲關聯	功能完整，性能提升顯著	SQL復雜，深度分頁仍有瓶頸	需要跳轉頁碼的傳統分頁
鍵集分頁	性能最佳且穩定	無法跳頁	無限滾動、上一頁/下一頁
業務限制	實現簡單，規避問題	功能受限	搜索結果等多數常規列表

結論：在設計分頁功能時，應優先考慮鍵集分頁方案以獲得最佳性能。如果必須支持跳轉任意頁碼，延遲關聯是一個有效的折中選擇。根據實際業務需求選擇最合適的策略，是解決深分頁問題的關鍵。