Go语言使用Scan从数据库解析数据过慢的优化咨询

针对你600条数据解析耗时130ms的问题，结合你的代码和场景，给出以下具体优化方向：

1. 先验证jsonb字段是否为性能瓶颈 #

你提到blockchain_info是jsonb类型，这大概率是主要耗时点：

• 数据库驱动在将jsonb类型转换为*string时，需要把二进制的jsonb数据序列化为字符串，这个过程涉及内存分配和序列化操作，600条累加后会产生明显开销。
• 验证方法：临时修改SQL查询，去掉blockchain_info字段，重新测试解析耗时。如果耗时大幅下降，说明这个字段是核心瓶颈。
• 优化方案：
  • 如果业务不需要该字段内容，直接从SQL中移除，避免不必要的序列化。
  • 如果必须使用，将字段类型从*string改为[]byte，直接存储jsonb的二进制数据，避免字符串转换的开销；后续需要解析时再按需反序列化为结构体，而非在Scan阶段就完成转换。
  • 若需要直接映射为结构体，可定义对应结构体类型，让驱动直接将jsonb反序列化为结构体（需驱动支持，比如pgx驱动支持pgtype.JSONB或直接映射到结构体）。

2. 预分配切片容量，减少内存扩容开销 #

你的代码中queryResult是零值切片，每次append都会在容量不足时触发内存扩容和数据拷贝，600条数据会多次触发这个操作：

// 原代码
var queryResult []Models.DictAsset

// 优化后：预分配足够容量
queryResult := make([]Models.DictAsset, 0, 600) // 600是预估的结果条数

预分配后可避免多次扩容的内存操作，能显著降低耗时。

3. 避免反射带来的额外开销 #

你尝试的反射版本Scan，本身就有一定性能损耗，和手动Scan耗时相近是正常的。如果要追求极致性能，避免在循环内使用反射，坚持手动Scan的方式，或者使用代码生成工具（如sqlboiler）生成自动映射的代码，既保留手动Scan的性能，又避免重复编写代码。

4. 复用结构体变量，减少内存分配 #

手动Scan的版本中，你复用了dictAsset变量，这本身是好的，但注意每次append都会拷贝结构体（因为结构体是值类型），不过这个开销很小。如果想进一步优化，可以直接操作预分配的切片：

queryResult := make([]Models.DictAsset, 600)
idx := 0
for rows.Next() {
    err := rows.Scan(&queryResult[idx].ID, &queryResult[idx].Asset, &queryResult[idx].LotSize, &queryResult[idx].Comment, &queryResult[idx].TradingAbbreviation, &queryResult[idx].BlockchainInfo, &queryResult[idx].MinimalAmount)
    if err != nil {
        log.Fatal(err)
    }
    idx++
}
queryResult = queryResult[:idx] // 处理实际条数不足600的情况

这种方式避免了append的拷贝操作，直接在预分配的切片中赋值，进一步降低内存操作开销。

5. 检查数据库驱动的配置 #

如果你使用的是PostgreSQL驱动（如pgx），确保开启了高效的模式：

• 使用二进制协议（pgx默认启用），比文本协议的序列化效率更高。
• 避免不必要的类型转换，比如驱动内部的额外处理，确保字段类型和数据库类型精准匹配。

通过以上步骤，尤其是解决jsonb的序列化问题和预分配切片，将解析耗时降到1ms以内是完全可行的。

内容的提问来源于stack exchange，提问作者EgorRedkozubov