gorm批量读取唯一可靠方式是findinbatches，需关闭预加载、事务和钩子，按主键或带索引的排序字段游标推进，批次大小设100–1000，禁用count干扰与n+1查询。
GORM 本身不是为数据挖掘设计的批量读取器，直接当“分页读取器”用容易内存爆掉或查漏数据——关键得关掉默认预加载、禁用事务、手动控制批次边界。
FindInBatches 是唯一靠谱的批量读取入口
别碰 Limit+Offset 做挖掘式遍历，百万级表上跑几轮就卡死。GORM 真正提供流式分批能力的只有 FindInBatches，它内部按主键游标推进，不依赖 OFFSET，也不扫全表。
- 必须传入切片指针（如
&results），不能传值；否则每批数据都覆盖前一批 - 回调函数里拿到的
tx *gorm.DB是带当前批次 WHERE 条件的新会话，可安全调Save、Updates，但别再套FindInBatches - 批次大小建议设 100–1000：太小导致 SQL 调用频繁；太大可能触发 MySQL 的
max_allowed_packet或 Go 内存 spike - 不要在回调里调
Preload——它会为每批结果单独发 N+1 查询，数据量大时直接拖垮 DB
避免 Count 干扰分批流程
数据挖掘任务通常不需要总数，硬查 Count 反而拖慢启动速度，且在高写入场景下数字很快过期。如果真要总数，必须用独立会话：
- 错：
db.Where(...).FindInBatches(...).Count(&total)→ 这个Count会继承前面的分批条件，结果是 0 或 batch size - 对：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where(...).Count(&total) - 更轻量：用
SELECT COUNT(*) FROM (SELECT 1 FROM users WHERE ...) t手写子查询，绕过 GORM 的链式污染
字段排序与索引是游标稳定的前提
FindInBatches 默认按主键 id 排序推进，但如果你加了 Order，就必须确保该字段有索引，否则游标失效：
- 用
Order("created_at DESC, id DESC")时，必须建联合索引INDEX idx_created_at_id (created_at, id)，单建created_at索引没用 - 禁止只用
Order("created_at DESC")—— 时间重复时游标跳批，同一条记录可能被跳过或重复处理 - 如果表没主键（比如日志表），必须显式指定排序字段并建索引，否则
FindInBatches行为不可预测
关闭 GORM 自动事务和钩子
数据挖掘是只读密集型任务，开启事务或 BeforeCreate 等钩子纯属浪费 CPU 和锁资源：
- 初始化 DB 时加
&gorm.Config{SkipDefaultTransaction: true} - 显式禁用钩子：
db = db.Session(&gorm.Session{AllowGlobalUpdate: true, Context: ctx})，避免隐式事务包裹 - 确认没全局注册
Callback，尤其检查是否误启了 soft delete 或 audit 日志钩子
真正难的不是写对 FindInBatches 调用，而是确保每批之间不因并发写入、索引缺失或钩子干扰而漏数——这些细节一漏，整个挖掘结果就不可信。
