在使用?LIMIT + OFFSET?分頁時，數據重復的風險不僅與排序字段的唯一性有關，還與數據變動（插入、刪除、更新）密切相關。以下是詳細分析：

一、數據變動如何導致分頁異常

1.?插入新數據

• 場景：用戶在瀏覽第 1 頁時，數據庫插入了新記錄。
• 問題：新記錄可能會 "擠入" 已瀏覽過的頁面，導致后續頁出現重復數據。
• 示例：

  sql

  -- 初始數據（按ID排序）
  ID  Name
  1   Alice
  2   Bob
  3   Charlie-- 第1頁：LIMIT 2 OFFSET 0 → 返回 ID=1,2
  -- 此時插入新記錄 ID=4
  -- 第2頁：LIMIT 2 OFFSET 2 → 返回 ID=3,4（原第2頁是ID=3，出現重復）
  

2.?刪除數據

• 場景：用戶瀏覽第 2 頁時，第 1 頁的某些記錄被刪除。
• 問題：第 2 頁數據前移，導致部分記錄在第 1 頁 "消失"，第 2 頁重復顯示。
• 示例：

  sql

  -- 初始數據（按ID排序）
  ID  Name
  1   Alice
  2   Bob
  3   Charlie
  4   Dave-- 第1頁：LIMIT 2 OFFSET 0 → 返回 ID=1,2
  -- 此時刪除 ID=1
  -- 第2頁：LIMIT 2 OFFSET 2 → 返回 ID=3,4（原第2頁是ID=3,4，但用戶已看過ID=3）
  

3.?更新排序字段

• 場景：用戶瀏覽第 1 頁時，某條記錄的排序字段被更新。
• 問題：記錄位置發生變化，導致分頁混亂。
• 示例：

  sql

  -- 按分數降序排列
  ID  Score
  1   90
  2   85
  3   80-- 第1頁：LIMIT 2 OFFSET 0 → 返回 ID=1,2
  -- 此時 ID=3 的分數更新為 95
  -- 第2頁：LIMIT 2 OFFSET 2 → 返回 ID=2,3（ID=2 重復）
  

二、書簽 / 鍵集分頁如何避免此問題

書簽分頁通過記錄絕對位置（如id > 100）而非相對偏移量，天然免疫數據變動影響：

• 插入新數據：新記錄不會影響已獲取的頁，只會出現在第一頁。
• 刪除數據：已獲取的頁不受影響，后續頁自動跳過缺失記錄。
• 更新排序字段：若更新影響排序，可能導致數據 "提前" 出現，但不會重復。

三、如何應對數據變動導致的重復問題

1.?業務層規避

• 場景：社交動態流、實時評論等高頻更新場景。
• 方案：
  • 改用書簽分頁，確保每次查詢基于固定位置。
  • 提供 "刷新" 按鈕，允許用戶重新獲取最新數據。

2.?數據庫層保障

• 事務隔離：在高一致性要求場景，使用REPEATABLE READ隔離級別，確保查詢期間數據視圖不變。
• 版本控制：為每條記錄添加version字段，每次更新時遞增，分頁時結合版本號排序。

3.?前端處理

• 去重邏輯：在前端維護已顯示的數據 ID 列表，重復數據自動過濾。
• 無限滾動優化：加載下一頁時，保留當前頁最后一條數據的 ID，與新頁第一條對比。

四、總結：風險場景與應對策略

場景	LIMIT+OFFSET 風險	書簽 / 鍵集分頁風險	應對方案
排序字段唯一 + 無數據變動	無	無	均可使用
排序字段不唯一 + 無數據變動	可能重復	無	添加唯一字段到 ORDER BY
排序字段唯一 + 有數據變動	可能重復	無	優先使用書簽分頁
排序字段不唯一 + 有數據變動	高風險	低風險	鍵集分頁 + 唯一字段 + 前端去重

在實際應用中，若數據變動頻繁且對一致性要求高，應優先選擇書簽 / 鍵集分頁，從根本上避免數據重復問題。若使用LIMIT + OFFSET 分頁，則需注意，當第一頁查詢之后（比如我的查詢條件每頁都是可用量>0，但是第一頁查詢之后，我在業務代碼中將第一頁的可用量全部置為0），再去查詢下一頁，其實會產生跳頁情況，因為此時原第一頁數據已經不符合查詢條件了，真正的第一頁會直接被跳過。