优先用 findinbatches 而非 limit+offset 做导出，因其基于主键游标分批，避免大 offset 导致的扫描开销；需确保有序索引、显式 order、合理处理内存与事务，并注意游标查询不保证绝对不重复。
直接结论：别用 Find 或 Limit+Offset 做导出，优先用 FindInBatches；它不是“语法糖”，而是基于主键游标的高效分批机制。
为什么 Limit+Offset 在导出场景下会越来越慢
当你要导出 500 万条日志，每批取 1000 条，到第 4000 批时，OFFSET 已达 3999000。MySQL/PostgreSQL 必须扫描并跳过前 399.9 万行——哪怕有主键索引，这个“跳过”动作仍要逐行计数，I/O 和 CPU 开销陡增。
常见错误现象：SELECT * FROM logs ORDER BY id LIMIT 1000 OFFSET 3999000 执行耗时从几毫秒涨到 2+ 秒，且越往后越卡；数据库连接池被长期占用，其他接口开始超时。
实操建议：
- 永远避免在导出类任务中动态拼接大
OFFSET - 如果必须用
Limit+Offset（比如前端分页），限制总页数（如最多查到第 1000 页），超出则提示“数据量过大，请按时间范围筛选” - 确认表上有
id（或你指定的排序字段）的升序索引，否则游标查询也无效
FindInBatches 的正确用法和关键约束
FindInBatches 不是“自动帮你循环”，它依赖两个隐含前提：有序、可比较的主键字段（默认是 id），且每次查询都以上一批的末尾 id 为起点。
典型写法：
err := db.Model(&Log{}).Where("created_at > ?", lastMonth).
Order("id").
FindInBatches(&logs, 1000, func(tx *gorm.DB, batch int) error {
// 处理这批 logs，例如写入 CSV 文件
writeBatchToCSV(logs)
return nil
})
注意点：
- 必须显式写
Order("id")，否则 GORM 可能不加或加错排序，导致漏数据或重复 - 回调函数里不要对
tx做额外Save/Delete，它只是只读批次上下文；要改数据请另起事务 -
batch参数是当前批次序号（从 1 开始），但不要依赖它做状态判断——真正可靠的锚点是上一批最后一条记录的id - 若导出需按时间排序而非主键，且时间字段无唯一性，必须补一个唯一联合条件（如
ORDER BY created_at, id），否则游标可能跳过或重复
导出时容易忽略的内存与事务陷阱
即使用了 FindInBatches，仍可能 OOM 或锁表——问题常出在“处理逻辑”本身。
常见错误现象：CSV 写入前把整批 logs 转成字符串再拼接，或在回调里调用 json.Marshal 全量序列化，导致单批次内存暴涨；又或者在回调里执行了另一个带事务的 DB 操作，造成长事务阻塞。
实操建议：
- 每次只处理一条记录就刷入文件流（
bufio.Writer+Flush），别攒整批再写 - 避免在
FindInBatches回调中调用任何会开启新事务的方法（如db.Transaction） - 如果导出需关联其他表（如用户昵称），用
JOIN或预加载一次性查出，别在循环里触发 N+1 查询 - 设置
db.Session(&gorm.Session{PrepareStmt: true})复用预编译语句，减少 Parse 开销
最易被忽略的一点：游标查询只保证“不漏”，不保证“不重”。如果导出过程中有新数据插入且 id 落在当前批次区间内，这批数据可能被跳过。严格一致性要求下，应配合时间范围锁定（如 WHERE created_at BETWEEN ? AND ?）并禁用写入，或接受最终一致性。
