GORM性能优化实战：从SQL生成到查询调优

1. 为什么GORM需要性能优化

第一次用GORM做项目时，我天真地以为ORM框架会自动处理好所有性能问题。直到某天线上服务突然报警，查日志发现一个简单的列表查询居然执行了3秒！打开数据库慢查询日志一看，差点没背过气去——GORM生成的SQL竟然包含了5个不必要的JOIN和3个子查询。

GORM作为Go语言中最流行的ORM框架，确实极大简化了数据库操作。但正是这种便利性，让很多开发者（包括当年的我）忽视了底层SQL的生成质量。当数据量增长到百万级时，那些被隐藏的性能问题就会突然爆发。

2. GORM的SQL生成机制解析

2.1 预加载的陷阱

GORM的Preload功能用起来非常顺手：

go复制db.Preload("Orders").Find(&users)

但你知道它实际执行的SQL吗？假设有100个用户，每个用户平均有5个订单，GORM会先执行：

sql复制SELECT * FROM users;

然后为每个用户执行：

sql复制SELECT * FROM orders WHERE user_id = ?;

这就是著名的N+1查询问题。100个用户意味着101次数据库往返！

解决方案：

go复制db.Preload("Orders", func(db *gorm.DB) *gorm.DB {
    return db.Select("id,user_id,amount") // 只查必要字段
}).Find(&users)

或者更好的方式是使用Join：

go复制db.Joins("LEFT JOIN orders ON users.id = orders.user_id").Find(&users)

2.2 链式调用的代价

GORM的链式调用非常灵活：

go复制db.Where("name LIKE ?", "%张%").
   Or("age > ?", 18).
   Order("created_at desc").
   Limit(10).
   Find(&users)

但每次链式调用都会创建一个新的DB实例。如果代码中有条件分支：

go复制query := db.Model(&User{})
if filterByName {
    query = query.Where("name = ?", name)
}
if filterByAge {
    query = query.Where("age > ?", age)
}

GORM会在内存中创建多个DB实例，影响性能。

优化方案：

go复制query := db.Model(&User{})
if filterByName || filterByAge {
    query = query.Where(func(db *gorm.DB) *gorm.DB {
        if filte