使用LIMIT + OFFSET 分页时，数据重复的风险

在使用 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），再去查询下一页，其实会产生跳页情况，因为此时原第一页数据已经不符合查询条件了，真正的第一页会直接被跳过。