详解GORM框架配合Go协程进行多通道分片分页读取-Golang-PHP中文网

gorm 不支持多通道分片分页读取，强行并发 offset 分页会导致数据重复、丢失、性能下降和不一致；正确做法是基于主键或时间戳的游标分片，配合独立 db 实例并发查询。

详解gorm框架配合go协程进行多通道分片分页读取

直接说结论：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 主键范围分片：

GORM框架 1.30.3

GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。

下载

先查全表 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})），避免共享状态
注意：区间右边界要用 ，左边界用 <code>>=，且所有分片 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