断点续传式批处理的sql本质是动态识别上一批已处理的最大标识值作为下一批起始条件，而非依赖外部状态；核心用相关子查询（如coalesce(max(id),0)）锚定业务进度，配合order by和索引保障一致性与性能。
什么是断点续传式批处理的SQL本质
断点续传式批处理在SQL中不是靠“状态保存”实现的，而是靠每次查询时动态识别「上一批已处理的最大标识值」，再用它作为下一批的起始过滤条件。核心在于：不能依赖外部变量或临时表记录进度，而要让每条SQL自己算出该取哪一段——相关子查询正是干这事的合适工具，尤其当主键/时间戳不连续、无法用简单 BETWEEN 切分时。
用相关子查询找「上一批最大id」并跳过已处理行
典型场景：按 id 递增更新用户积分，每次处理1000条，但中间可能失败，重启后得从最后成功更新的 id 继续。此时不能写 WHERE id > 12345 LIMIT 1000（因为12345是硬编码），而要用相关子查询动态获取：
SELECT * FROM users u1 WHERE u1.id > ( SELECT COALESCE(MAX(u2.id), 0) FROM users u2 WHERE u2.status = 'processed' ) ORDER BY u1.id LIMIT 1000;
关键点：
-
COALESCE(MAX(u2.id), 0)防止全没处理过时返回NULL导致整个查询无结果 - 子查询里必须加
WHERE u2.status = 'processed'，且该字段需有索引，否则性能暴跌 - 外层
ORDER BY u1.id不可省——LIMIT在无序结果上行为不确定 - 如果用时间字段（如
updated_at）代替id，注意时区和精度问题，重复值会导致漏数据
避免OFFSET陷阱：为什么不用 LIMIT offset, size
有人想用 LIMIT 10000, 1000 模拟分页续传，但这是错的：OFFSET 越大越慢，且若中途有新数据插入，OFFSET 位置会偏移，导致重复或遗漏。相关子查询绕开了OFFSET，直接锚定业务状态（如已标记为 processed 的最大id），天然具备一致性。
常见错误现象：
- 第1次跑完1–1000，第2次用
LIMIT 1000, 1000，结果发现第1001条其实是新插入的，原第1001条被跳过了 - 子查询漏加
WHERE条件，查出全表MAX(id)，导致一批都不处理 - 外层没加
ORDER BY，MySQL 8.0+ 可能返回非预期顺序，PostgreSQL 直接报错
生产环境必须加的防护措施
真实场景中，光靠相关子查询不够，还得配合业务字段和事务控制：
- 更新前先用相关子查询查出待处理批次，再用
UPDATE ... WHERE id IN (SELECT ...)批量更新，避免逐行锁表 - 给
status字段加复合索引，例如INDEX idx_status_id (status, id)，让子查询走索引覆盖 - 若用时间字段，务必在更新语句里加上
AND updated_at 类条件，防止幻读干扰子查询结果 - 相关子查询里的表别名（如
u1和u2）必须区分清楚，否则变成非相关子查询，逻辑完全失效
最易被忽略的是索引——没有对应索引时，子查询会触发全表扫描，10万行就卡死；而加上索引后，哪怕千万级表也能毫秒级定位断点。
