刚开始写数据同步、批量导出或历史回放任务时，很多人都会用一段很熟悉的分页逻辑：
SELECTid,user_id,status,updated_atFROMuser_eventWHEREupdated_at>=:startTimeANDupdated_at<:endTimeORDERBYupdated_atLIMIT:pageSizeOFFSET:offset;代码侧不断增加offset：
intpageSize=500;intoffset=0;while(true){List<UserEvent>events=repository.findByPage(startTime,endTime,pageSize,offset);if(events.isEmpty()){break;}syncService.process(events);offset+=pageSize;}这段代码很容易被 AI 写出来。
它看起来也完全合理：
- 有时间范围；
- 有排序；
- 有分页；
- 有终止条件；
- 每次处理固定数量的数据。
如果表里的数据完全不变，它通常能正常跑完。
但真实系统里，数据往往不会在同步期间静止。
只要有新的事件写入、旧数据状态更新、同一时间戳的记录顺序变化，LIMIT + OFFSET就可能让你遇到两种最麻烦的问题：
- 某些记录被重复处理；
- 某些记录被直接跳过。
更糟的是，任务大概率不会报错。
它会显示“已同步完成”，但最终数据并不完整。
一、OFFSET 为什么会在数据变化时失效
假设你要同步一段时间内的事件数据，当前按updated_at排序。
第一次查询：
OFFSET 0, LIMIT 3 A B C此时刚好有一条更早排序的数据X被更新，进入了当前查询范围：
X A B C D E F第二次查询仍然执行：
OFFSET 3, LIMIT 3得到的可能是：
C D E注意，C被重复拿到了。
因为X插入到前面后，原本的分页位置整体后移了。
再看另一种情况。
第一次查询已经处理：
A B C处理期间，A被归档、删除，或者状态改变后不再满足条件，数据集变成：
B C D E F第二次依旧从OFFSET 3开始：
E F那么D就被跳过了。
这就是 OFFSET 分页的核心问题：
OFFSET 不是“从上次处理到的位置继续”，而是“从当前结果集的第 N 行开始”。
只要结果集在两次查询之间发生变化，N的含义就变了。
二、一个错误但常见的补救方式：加大分页大小
发现同步慢或者数据有遗漏时，有人会尝试：
intpageSize=5000;或者干脆一次查更多：
LIMIT10000OFFSET:offset;这可能让问题“看起来少发生一些”，但不能从根本上解决。
分页大小变大后，风险只是从“更多页之间的数据变化”变成“单页查询更重、锁更久、失败重跑代价更高”。
它还可能带来新的问题：
| 做法 | 看起来的好处 | 实际风险 |
|---|---|---|
增大pageSize | 查询次数减少 | 单次内存占用更高 |
增大pageSize | 同步更快 | 失败后重试范围更大 |
增大pageSize | 少一些 OFFSET | 仍然可能重复或漏数据 |
| 一次查全量 | 逻辑简单 | 容易拖垮数据库或任务节点 |
| 不排序直接分页 | SQL 更短 | 返回顺序不稳定，问题更严重 |
真正需要修复的不是页大小，而是“下一页从哪里开始”的定义。
三、正确思路：用稳定游标代替 OFFSET
对于持续变化的数据集，更可靠的方式是使用游标分页，也叫 Keyset Pagination。
核心思想是：
不要记“已经跳过了多少行”，而要记“上一次处理到哪条记录”。
例如按updated_at和id组成稳定排序：
SELECTid,user_id,status,updated_atFROMuser_eventWHEREupdated_at>=:startTimeANDupdated_at<:endTimeAND(updated_at>:lastUpdatedAtOR(updated_at=:lastUpdatedAtANDid>:lastId))ORDERBYupdated_atASC,idASCLIMIT:pageSize;这里为什么要用两个字段？
因为单独用updated_at不一定唯一。
多个事件可能在同一秒、同一毫秒写入。如果只记录时间：
WHEREupdated_at>:lastUpdatedAt那么和上次最后一条记录时间相同的数据，会被直接跳过。
因此需要一个稳定、唯一的次级排序字段，例如主键id。
游标状态可以这样定义：
publicrecordSyncCursor(LocalDateTimelastUpdatedAt,LonglastId){}处理完一页后，不是增加offset，而是保存最后一条记录的位置：
publicSyncCursorprocessPage(List<UserEvent>events,SyncCursorcurrentCursor){for(UserEventevent:events){syncService.process(event);}UserEventlast=events.get(events.size()-1);returnnewSyncCursor(last.getUpdatedAt(),last.getId());}下一页从这个游标之后继续。
这样即使前面插入或删除了其他记录，已经处理过的位置仍然是确定的。
四、排序字段不稳定，游标分页也会出问题
很多人看到游标分页后，会立刻写成：
WHEREid>:lastIdORDERBYid这个方案在某些场景里没有问题，例如：
- 数据只追加、不更新；
- 主键和业务写入顺序强相关；
- 任务只处理创建后的新记录；
- 不需要捕获历史记录的后续状态变化。
但如果你的同步依据是“数据最近被修改过”，只按id就不够。
举个例子：
| id | status | updated_at |
|---|---|---|
| 100 | PENDING | 10:00:00 |
| 101 | PENDING | 10:01:00 |
| 102 | PENDING | 10:02:00 |
任务已经同步到id = 102。
此时id = 100的状态被修改为SUCCESS，updated_at变成10:05:00。
如果后续只使用：
WHEREid>102这条更新永远不会再次被同步到。
所以先要确定业务事实：
你是在同步“新增记录”？ 还是在同步“最近发生变化的记录”？前者可以考虑按递增 ID 游标。
后者通常需要按updated_at + id，并且要处理时间窗口重叠。
五、不要把时间窗口切得刚刚好
假设任务每 5 分钟跑一次：
10:00:00 - 10:05:00 10:05:00 - 10:10:00如果某条数据在 10:04:59 发生写入，但数据库提交、事件写入、时钟差异或延迟让它在 10:05:01 才可见，就可能落在两个窗口之间。
因此，实际增量同步常会使用“重叠窗口”：
本次查询窗口： 上次成功时间 - 2 分钟 到 当前安全水位时间例如：
WHEREupdated_at>=:lastSuccessTimeMinusOverlapANDupdated_at<:safeWatermark这会带来一定重复，但重复并不一定是坏事。
关键是消费侧要具备可验证的去重或幂等策略。
这里要区分：
- 查询层允许少量重叠，避免漏数据；
- 处理层防止重复副作用，避免重复写入或重复通知。
新人很容易只盯着“不要重复”。
但在同步任务里，通常比重复更危险的是漏数据。
六、让 AI 先帮你画数据边界，不要直接让它补分页代码
如果你只问：
帮我给同步任务加分页。AI 很可能会生成LIMIT + OFFSET，因为这是最常见、最容易理解的答案。
更有效的提问方式是：
你是后端数据同步方案评审助手。 场景： 我要同步 user_event 表中最近发生变化的记录。 同步过程中可能有新数据写入、旧记录状态更新、记录删除和任务重跑。 请不要直接使用 LIMIT + OFFSET。 请输出： 1. 应使用哪些稳定排序字段； 2. 游标应该保存哪些状态； 3. 相同 updated_at 的记录如何避免遗漏； 4. 时间窗口是否需要重叠； 5. 任务中断后如何断点续跑； 6. 哪些情况下可能重复处理； 7. 至少 6 个并发和异常测试场景； 8. 哪些判断需要由业务方确认。这类 Prompt 的价值，在于把“分页”从一个 SQL 语法问题，变成一个数据完整性问题。
对刚开始用 ChatGPT Plus 做代码解释、查询设计和异常排查的开发者来说，工具接入准备不只是让 AI 帮你补循环代码，还包括明确数据边界、保存过程状态、记录异常原因和验证最终结果。
第一次把 AI 工具纳入开发工作流时，建议把使用说明、异常处理和信息留存方式一起整理；相关准备项可按实际需要参考：gpt328
七、至少要测试这些场景
分页同步不是“查到数据就处理”的简单循环。
建议至少覆盖下面这些场景：
| 测试场景 | 预期结果 |
|---|---|
| 数据完全静止 | 全部记录恰好处理一次 |
| 同步期间有新记录插入 | 不影响已处理游标 |
| 同步期间旧记录被更新 | 后续窗口能捕获更新 |
多条记录updated_at相同 | 不因时间相同而遗漏 |
| 任务处理中断 | 从保存的游标继续，不从头重复 |
| 某页处理失败 | 游标不能提前推进 |
| 时间窗口重叠 | 可重复读取，但处理结果不重复 |
| 删除或归档前序记录 | 后续游标不会跳过未处理数据 |
例如，可以验证“相同更新时间的记录不会漏掉”：
@TestvoidshouldNotSkipRecordsWithSameUpdatedAt(){LocalDateTimesameTime=LocalDateTime.of(2026,6,24,10,0,0);repository.saveAll(List.of(event(101L,sameTime),event(102L,sameTime),event(103L,sameTime)));SyncCursorcursor=newSyncCursor(sameTime,101L);List<UserEvent>result=repository.findAfter(cursor,100);assertEquals(List.of(102L,103L),result.stream().map(UserEvent::getId).toList());}再验证“处理失败时游标不能被错误推进”：
@TestvoidshouldNotAdvanceCursorWhenPageProcessingFails(){List<UserEvent>events=List.of(event(101L),event(102L),event(103L));doThrow(newSyncException("downstream unavailable")).when(syncService).process(events.get(1));assertThrows(SyncException.class,()->syncTask.process(events));assertEquals(originalCursor,cursorRepository.load("user-event-sync"));}这里的原则很简单：
游标代表“已经确认处理完成的位置”，不是“已经读取到的位置”。
八、上线后要观察什么
分页同步如果出了问题，通常不会直接抛出明显异常。
更常见的是：
- 处理数量看似正常，但下游少了一部分数据；
- 某些记录不断被重复同步；
- 游标卡住不动；
- 任务一直成功，但延迟越来越大；
- 某个时间段的数据永远没有进入下游系统。
因此建议至少记录：
sync_cursor_updated_at sync_cursor_last_id sync_page_size sync_processed_count sync_duplicate_count sync_failed_count sync_lag_seconds sync_last_success_time最关键的是：
- 当前游标停在哪里；
- 距离当前数据最新时间差多少；
- 每页实际处理了多少条；
- 重复数量是否突然升高；
- 是否存在连续成功但游标不前进的情况。
不要只看“任务执行成功”。
任务成功只说明代码没有抛异常，不说明数据真的完整到达了目标系统。
九、结语
LIMIT + OFFSET适合静态列表翻页，也适合一些后台页面展示。
但它并不天然适合持续变化的数据同步。
当数据会新增、更新、删除，或者任务需要中断恢复时，更重要的是：
- 排序是否稳定；
- 游标是否能够准确表达处理进度；
- 相同时间戳的数据是否会漏；
- 时间窗口是否需要重叠；
- 失败时游标会不会被提前推进；
- 重复与遗漏分别由哪一层负责处理。
AI 可以很快帮你写出分页循环。
但同步任务真正难的部分，从来不是while循环，而是如何定义“这批数据已经被完整、可靠地处理过”。
最危险的不是任务失败。
而是任务显示成功，却悄悄漏掉了你最需要的数据。
