面经策

使用 LIMIT OFFSET 进行分页同步时，发现数据丢失了，可能是什么原因？如何解决？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

LIMIT OFFSET 分页同步丢数据——这是分页窗口在动态数据上移动导致的经典问题，我先把机理讲透，再给根治方案。

为什么丢（或重）

假设按 id 排序 LIMIT 100000, 1000 翻页，同步过程中：

  • 删除：前面页的数据被删掉 → 后面的行"前移" → 某些行被跳过（丢数据）
  • 插入（排序键非递增场景，如按 update_time）：新数据插到已翻过的页 → 永远同步不到
  • OFFSET 基准漂移：每一页的 OFFSET 都基于"当时的快照"，而数据在翻页间隙持续变化——分页一致性没有保障，这是原理性缺陷不是 bug

根治方案

1. 游标分页（首选）

sql
-- 用上一页最后一条的排序键做锚点
SELECT * FROM t WHERE id > #{lastId} ORDER BY id LIMIT 1000;

锚点之前的数据变化不影响后续页——只要求排序键稳定且趋势递增（自增主键、业务时间+主键复合游标）。删除不丢（锚点已过）、插入在锚点后必被扫到。

2. 时间区间切分：按 create_time/update_time 划定同步窗口（每小时一个任务），窗口闭合后重扫校验。

3. 快照读：START TRANSACTION WITH CONSISTENT SNAPSHOT（或 MySQL 8.0 AS OF），整个分页过程读同一一致性视图——代价是长事务、undo log 膨胀，大表慎用。

4. 换 CDC：结构性方案是放弃拉取式分页，走 binlog 增量推送（Canal/Flink CDC），从"反复查询"变成"订阅变更"。

业务收尾：数据丢失最危险的地方在于静默——同步没报错、报表数字就是少了一点，直到财务对账才炸。所以游标改造之外，我一定加总量对账（源 vs 目标 count/sum 按天核对）：修复机制解决已知问题，对账机制发现未知问题，两手都要有。

🏗 系统架构师 ​

LIMIT OFFSET 分页同步丢数据，根因是**"活表上的快照假设不成立"**——边同步边有写入，翻页的"窗口"在移动。我分两个典型场景讲。

场景一：新插入数据丢失（深翻页跳过）WHERE id > lastMaxId ORDER BY id LIMIT 1000 逐批拉取时，如果同步中已有数据被更新且新值导致重排，或者用非主键排序翻页：某条记录第一次查询时排在第 2001 行之后，翻到后面页时它前面被插入了新数据（或被更新），它"后移"进了已翻过的页——永远取不到。 经典图景：按 create_time 排序翻页，同步期间新数据 create_time 更大不影响；但按 update_time 排序就会丢——更新会让记录在排序空间里"漂移"。

场景二：OFFSET 与删除的交互LIMIT 1000 OFFSET 5000 拉取期间前面有 200 行被删除，OFFSET 5000 实际跳到了 5200 的位置，中间 200 行没被同步。

解决方案（按推荐度）：

  1. 主键游标翻页（治本）：
sql
SELECT * FROM t WHERE id > #{lastId}
ORDER BY id ASC LIMIT 1000;

只向后推进，新插入（id 更大）自然被后续批次覆盖，删除不影响游标；已同步行的更新靠增量链路（binlog CDC）补充——全量快照 + 增量追平的组合。

  1. 快照一致性读：事务隔离级别 REPEATABLE READ 下，同一个长事务内的翻页读的是同一份 MVCC 快照，翻页期间写入不干扰。注意长事务的代价（undo log 膨胀、影响 purge），大表分批提交就失效，只适合中小表。

  2. 时间区间分片：按 create_time 切成不可变的历史区间（昨天之前的分片数据不再变），分片内即使 OFFSET 翻页也安全；当天热数据走增量。

  3. 同步后校验兜底：无论如何翻页，都做分片 count 对账，差异重拉。

一句话：游标代替 OFFSET、快照或分片消灭"移动的窗口"、CDC 增量兜住更新，三者组合才敢说同步不丢。

💻 全栈开发专家 ​

这是我踩过的真实坑。LIMIT OFFSET 分页同步丢数据，根因是**"分页游标不基于稳定快照 + 排序键会移动"**，具体三类：

三个根因

  1. 新插入挤位：按 id 排序翻页时新数据插到了已扫过的页（排序键不是"只增不改"的语义），导致重复；配合去重逻辑又可能连锁跳数据。
  2. 删除让位：翻页期间前面的行被删，OFFSET 整体前移，下一页"跳过"了本该出现的行——这是最典型的"丢数据"。
  3. 排序不稳定：ORDER BY update_time 这类非唯一键，同一秒多行在不同页之间顺序漂移，MySQL 不保证分页间顺序一致，重复和遗漏并存。此外每次查询是独立快照（RRRR 隔离级别下各查询看到的版本不同），加剧以上问题。

正确解法：游标法（seek method）

sql
-- 记录上一批最后一行的 (update_time, id)，下一批：
SELECT * FROM orders
WHERE (update_time, id) > (?, ?)   -- 行值比较，或拆成 OR 写法
ORDER BY update_time, id
LIMIT 1000;

游标永远向前，新插在前面的数据不会造成重复，删除也不会让窗口平移；update_time + id 复合排序保证稳定全序。

兜底建议

  • 有唯一自增 id 且只同步新增，直接 WHERE id > ? 最简单可靠。
  • 有更新需求（update_time 游标），更新时间可能被回拨，要加"延迟双读"或对账兜底。
  • 根治方案是放弃扫表，上 binlog CDC，变更事件天然不依赖查询快照——这也是我最终迁移的方向：分页同步只留作对账工具。