offset必须禁用——它在百万级表上引发全表扫描式丢弃，导致同步延迟飙升；应改用基于主键的游标分页，以lastid为起点分批拉取，确保索引覆盖、避免漏重，并用id区间替代总数预估进度。
数据仓库同步任务中用 GORM 做大分页读取，Offset 必须禁用——它在百万级以上表上会触发全表扫描式丢弃，同步延迟飙升且拖垮数据库。
为什么 Offset 在同步任务里完全不可用
同步任务通常要扫全量或增量历史数据，OFFSET 100000 不是“跳到第 10 万条”，而是让 MySQL/PostgreSQL 先读、排序、丢弃前 10 万行。数据越老，偏移越大，单次查询耗时从毫秒级涨到秒级甚至超时。
- 常见错误现象：
db.Offset(499999).Limit(1000)在 500 万行用户表上执行超 2.3 秒，CPU 持续 95%+，下游同步链路卡住 - 即使加了
ORDER BY id ASC，只要没索引覆盖，仍会回表；而同步任务常需查几十个字段，SELECT *+OFFSET几乎必然触发磁盘 IO 瓶颈 - 事务中多次
Offset查询，若中间有新写入，同一逻辑页可能漏掉或重复处理记录（GORM 不提供快照隔离）
用游标分页替代 Offset 的实操要点
游标分页本质是“基于上一批最后一条的主键值继续往后拉”，绕开物理扫描，但必须严格对齐条件和索引。
- 首次查询固定用：
db.Order("id ASC").Limit(batchSize).Find(&records)，不带Where，确保拿到最小 ID 起点 - 后续批次必须用：
db.Where("id > ?", lastID).Order("id ASC").Limit(batchSize).Find(&records)，lastID来自上一批records[len(records)-1].ID -
id字段必须是主键或有唯一非空索引；若用created_at，务必搭配id作为二级排序（Order("created_at ASC, id ASC")），避免高并发下时间重复导致漏数据 - 前端不传页码，后端也不解析
page参数——同步任务是后台作业，直接由 Worker 控制游标推进，lastID存在 Redis 或本地变量即可
如何安全地处理删除与并发写入
同步过程中源表可能被删行或新增，游标分页本身不解决一致性问题，得靠策略兜底。
- 不要依赖单次查询的“总数”做进度预估——
Count()和主查询之间若有写入，总数就失效；改用“已处理 ID 区间”汇报进度（如processed_range: "1-10000"） - 若业务允许，同步前对源表加
READ ONLY或使用快照事务（MySQL 用START TRANSACTION WITH CONSISTENT SNAPSHOT），但注意长事务会阻塞 purge - 更稳妥的做法：把同步拆成“按 ID 段切分”，例如每批处理
id BETWEEN ? AND ?，段大小固定（如 10000），用db.Raw()手写 SQL 避免 GORM 的链式污染，同时段边界可并行调度 - 每次批次结束后，用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("id 单独查该段内是否发生软删，补漏
批量读取时的 GORM 性能陷阱
GORM 默认每条记录建一个 struct 实例，大数据量下内存分配和 GC 压力明显；同步任务应优先控制查询粒度和返回字段。
- 永远用
Select("id, name, email, updated_at")显式指定字段，避免SELECT *—— 尤其当表有 TEXT/blob 字段时，IO 和网络开销剧增 - 别在同步循环里反复调
Preload，它会为每批生成 N+1 查询；如需关联数据，改用Joins+Scan到匿名 struct，或分两阶段：先拉主表 ID 列表，再用IN批量查关联表 - 批量大小（
batchSize）不是越大越好：MySQL 默认max_allowed_packet=64M，设成 10000 条可能超限；建议 500–2000，视单条平均体积调整 - 用
Rows()+Scan替代Find()可减少反射开销，尤其字段数多时：rows, _ := db.Table("users").Select("id,name").Where("id > ?", lastID).Rows()
游标分页不是“换种写法”，而是同步任务的数据读取契约——它要求你放弃页码思维，接受基于位置的流式推进；最容易被忽略的是：lastID 必须来自当前批次的**最后一条有效记录**，而不是随便取 records[0].ID 或 MAX(id)，否则会跳段或重复。
