GORM 不支持多通道分片分页读取，强行并发 Offset 分页会导致数据重复、丢失、性能下降和不一致；正确做法是基于主键或时间戳的游标分片，配合独立 DB 实例并发查询。
直接说结论：GORM 本身不支持“多通道分片分页读取”，强行用 Go 协程 + 多个 db.Limit().Offset() 并发查，只会放大传统分页的缺陷——数据重复、丢失、性能崩盘，且无法保证一致性。
为什么不能用协程并发跑多个 Offset 分页
很多人想“加速分页”，就开 4 个 goroutine，分别查 page=1~4，每页 100 条。这在逻辑上就错了：
-
OFFSET是数据库扫描并丢弃前 N 行的物理操作，不是跳转指针；4 个并发查询会各自扫描大量重复行（比如 page=3 和 page=4 都要扫前 200 行），IO 和 CPU 反而翻倍 - 若期间有新记录插入（如按
created_at DESC排序），page=2 最后一条和 page=3 第一条可能来自同一秒，导致某条记录被漏掉或重复返回 - GORM 的
*gorm.DB实例不是线程安全的——如果你复用同一个 db 实例在多个 goroutine 里调Where()、Order()，条件会互相污染（尤其用了Session()但没设NewDB: true） - 总数统计
Count()和分页查询不在同一事务快照下，total和实际可分页条数天然不一致
真正可行的“分片读取”只有一种：基于主键/时间戳的游标分片
想并发读，必须放弃“页码”概念，改用确定性位点（cursor）切分数据空间。例如对 id 主键范围分片：
- 先查全表 min(id) 和 max(id)：
db.Raw("SELECT MIN(id), MAX(id) FROM users").Scan(&minID, &maxID) - 按步长切片，如步长 = 10000，则生成区间：
[minID, minID+9999]、[minID+10000, minID+19999]… - 每个 goroutine 独立执行：
db.Where("id BETWEEN ? AND ?", start, end).Order("id ASC").Find(&users) - 每个 goroutine 必须使用独立的
*gorm.DB实例（推荐db.Session(&gorm.Session{NewDB: true})），避免共享状态 - 注意：区间右边界要用
<=，左边界用>=，且所有分片 WHERE 条件必须互斥无重叠
游标分片 + 协程的实际写法（带错误防护）
以下是一个安全启动 3 个 goroutine 并行读取用户数据的片段：
// 假设已知 id 范围 [1, 30000]
shards := [][]int{{1, 10000}, {10001, 20000}, {20001, 30000}}
var wg sync.WaitGroup
var mu sync.RWMutex
var allUsers []User
for _, shard := range shards {
wg.Add(1)
go func(r []int) {
defer wg.Done()
// 每个协程创建干净 DB 实例
shardDB := db.Session(&gorm.Session{NewDB: true})
var users []User
// 显式 Order + 索引字段 WHERE，避免优化器走错索引
err := shardDB.Where("id >= ? AND id <= ?", r[0], r[1]).
Order("id ASC").
Find(&users).Error
if err != nil {
log.Printf("shard [%d,%d] error: %v", r[0], r[1], err)
return
}
mu.Lock()
allUsers = append(allUsers, users...)
mu.Unlock()
}(shard)
}
wg.Wait()
- 别用
Offset，哪怕只在一个 goroutine 里用也不行 - 所有 WHERE 字段（如
id）必须有索引，否则分片查询退化为全表扫描 - 如果表用
created_at分片，注意 MySQL 的DATETIME(3)精度问题，高并发下相同毫秒值会导致分片重叠 - 最终合并结果时，若需全局有序，得再做一次
sort.Slice(allUsers, ...)，因为分片间不保证跨 goroutine 顺序
更现实的建议：别硬扛“多通道分片读取”
除非你在做离线 ETL 或数据库迁移，否则生产接口几乎不需要这种模式。它带来的复杂度远高于收益：
- 前端无限滚动 → 用单游标（
last_id）+ 向下拉取，简单可靠 - 后台导出百万数据 → 用单 goroutine + 游标分页 +
Rows()流式读，内存可控 - 真要提速 → 优化单次查询：加复合索引、关掉
Preload、用Select()只取必要字段 - 横向扩展瓶颈 → 加只读从库、用连接池调优（
MaxOpenConns）、而不是堆 goroutine
最易被忽略的一点：GORM 的 Find() 默认把整批结果加载进内存。分片再并发，等于把内存压力乘以 goroutine 数——没压垮数据库，先 OOM 了。
