Golang中的迭代器模式与数据库游标遍历 Go语言处理百万级数据读取

哈喽！今天心血来潮给大家带来了《Golang中的迭代器模式与数据库游标遍历 Go语言处理百万级数据读取》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

Go中无通用迭代器接口，database/sql.Rows需手动调用Next()和Scan()流式读取，及时Close()防连接泄漏，避免反射开销与分页性能陷阱。

Go 里没有内置迭代器接口，range 不是万能的

Go 语言标准库不提供类似 Java Iterator 或 Python __iter__ 那样的通用迭代器抽象。你不能对任意结构体直接写 for item := range obj——除非它实现了 Go 的「可 range 类型」：数组、切片、map、channel、字符串。数据库游标显然不属于其中。

所以想用「迭代器模式」遍历百万级结果，得自己封装状态和移动逻辑，而不是幻想有个 Next() 方法自动帮你推进。

• database/sql.Rows 本身就是游标式结构：调用 rows.Next() 才真正从底层驱动拉下一行，配合 rows.Scan() 解包，这才是真正的逐行流式读取
• 别提前把所有结果 rows.Columns() + rows.SliceScan() 拉进内存——那会瞬间吃光几百 MB，甚至触发 OOM
• 注意 rows.Err() 必须在循环结束后检查：rows.Next() 返回 false 时，错误可能藏在 rows.Err() 里，不是 nil

sql.Rows 的生命周期和连接池绑定很紧

很多人以为 rows 是个纯数据容器，其实它强依赖底层 *sql.Conn，而后者来自连接池。一旦你没及时 rows.Close()，连接就一直被占着，很快耗尽 db.SetMaxOpenConns() 设置的上限，后续查询卡死在 acquireConn 阶段。

• 必须在 for rows.Next() 循环结束后立刻调用 rows.Close()，哪怕中间 break 或 return，也要用 defer rows.Close() 包住
• 不要把 rows 传给其他 goroutine 去消费——不同 goroutine 并发调用 Next() 会竞争内部状态，行为未定义
• 如果需要跨 goroutine 分发数据，先用 channel 中转，且确保 rows 在本 goroutine 内完成关闭

处理百万行时，Scan() 的字段绑定方式影响性能和稳定性

每调用一次 rows.Scan()，Go 就要反射解析目标变量类型、做类型校验、分配临时缓冲区。对百万行来说，这点开销会被放大。

• 优先用具体类型指针，比如 var id int64; var name string; rows.Scan(&id, &name)，避免 interface{} + 类型断言
• 别用 sql.NullString 等包装类型除非真要区分 NULL 和空字符串——它们额外增加字段判空逻辑和内存分配
• 如果字段多且固定，考虑用 Rows.Scan() 配合结构体字段地址数组（[]interface{}），但要注意每次循环都要重置指针值，否则第二次扫描会写错位置

游标分页 vs. 游标流式读取，别混淆概念

业务常说的「游标分页」（比如用 last_id 或 created_at 做 where 条件）和数据库驱动层的「游标遍历」（sql.Rows）是两回事。前者是应用层翻页策略，后者是底层数据拉取机制。

• 用 LIMIT OFFSET 做分页查百万级数据？跳过前 99 万行时，MySQL 仍要扫描并丢弃它们，I/O 和 CPU 成倍增长
• 真要分页，优先用无状态游标：WHERE id > ? ORDER BY id LIMIT N，配合上一页最后的 id 值
• 但如果目标只是「全量导出/清洗/聚合」，就别分页，直接用 rows.Next() 流式读，省掉 N 次 round-trip 和重复排序

最常被忽略的一点：驱动返回的 rows 默认不支持 Seek() 或 Reset()，也没法倒带。游标只向前，且不可重用——想重读，只能重新执行查询。

今天关于《Golang中的迭代器模式与数据库游标遍历 Go语言处理百万级数据读取》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！