大王的代码日记

GORM 的 First、Take 与 Last：差别不在语法，在生成的 SQL

#Go#GORM#数据库

GORM 提供了三个看起来很相似的方法：

db.First(&user)
db.Take(&user)
db.Last(&user)

刚接触的时候很容易把它们当成同一件事的不同写法。实际上它们生成的 SQL 差别很大，而且在特定表结构下，这个差别会直接变成 bug。

三者的 SQL 到底长什么样

对着 SQLite 开 Debug() 看一眼就清楚了：

db.Debug().First(&user)
// SELECT * FROM `users` ORDER BY `users`.`id` LIMIT 1

db.Debug().Take(&user)
// SELECT * FROM `users` LIMIT 1

db.Debug().Last(&user)
// SELECT * FROM `users` ORDER BY `users`.`id` DESC LIMIT 1

区别就是两点：

方法 ORDER BY 语义
First id ASC 主键最小的一条
Take 无 数据库返回的第一条
Last id DESC 主键最大的一条

Take 的「无 ORDER BY」意味着什么

Take 不指定排序，意味着顺序由数据库执行计划决定。它可能是插入顺序，可能是某个索引的顺序，也可能随数据量变化而改变。

这带来两个后果：

第一，结果不稳定。 同一条语句，今天返回 A，明天数据分布变了可能返回 B。如果你只是要「随便拿一条」（比如取一条待处理任务），这是可以接受的；但如果你想的是「取最新的一条」，那 Take 是错的。

第二，它的语义是「不要排序」而不是「不关心顺序」。 Take 常常更快，因为它省掉了排序步骤，可以直接用主键索引的第一条。但这里的性能差异要实测，因为数据量小时排序开销可以忽略，数据量大时索引本身也会影响计划。

真正的坑：主键不是自增时

上面三个方法的排序全部基于主键。这一点在自增整型主键上没问题——主键顺序就等于插入顺序。

但如果主键是 UUID 或者雪花 ID：

type Article struct {
    ID   string `gorm:"primaryKey;type:uuid"`
    Title string
}

那么 First 返回的就是主键字典序最小的那条，而不是最早的或最新的。Last 同理。

这时候业务语义就崩了：你以为在取「最新一篇」，实际上在取「UUID 最小的那篇」。

正确的做法是显式按时间排序，不要依赖 First / Last 的隐含排序：

db.Order("created_at DESC").First(&article)
// SELECT * FROM `articles` ORDER BY created_at DESC LIMIT 1

注意这里 First 自带的 ORDER BY id 会被你的 Order 覆盖掉，这是符合直觉的。

Model 又是另一回事

顺带说一句 Model，它经常和上面三个一起被混淆。

Model(&user) 的作用是指定操作的目标模型，主要用于：

  • 更新、删除时告诉 GORM 操作哪张表：db.Model(&User{}).Where("age > ?", 18).Update("status", "adult")
  • 作为后续链式调用的类型上下文

它不会帮你取数据，也不会自动加条件。db.Model(&user) 单独调用不产生任何 SQL。

一个常见误用是：

// 错：这不是查询，只是一个空操作，user 仍然是零值
db.Model(&user)
fmt.Println(user.Name) // ""

判断标准

选哪个，其实可以先问一句：这条记录的顺序有业务含义吗？

  • 有（最新、最早、优先级最高）→ 显式写 Order，别用隐含排序
  • 没有（随便一条就行）→ Take，省掉排序
  • 主键是自增且你就想要最小 / 最大的那条 → First / Last 可以用，但最好加注释说明依赖主键顺序

最后一条尤其重要。因为「依赖主键顺序」这件事，在一个主键类型被改掉的迁移里会静默失效——SQL 照样跑，结果悄悄变了。

怎么验证

养成一个习惯：在开发环境打开 Debug()，把生成的 SQL 打出来看一眼。

db = db.Debug()

所有查询都会打印实际执行的 SQL，包括 ORDER BY 和 LIMIT。这比看文档快得多，也比看文档可靠得多——文档会更新，你表上的索引和执行计划才是事实。

友情链接