mysql8.0中如何用函数求分组内的第一条记录_使用FIRST_VALUE窗口函数

MySQL 8.0 中如何用函数求分组内的第一条记录：使用FIRST_VALUE窗口函数

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

开门见山，先说一个核心结论：FIRST_VALUE()这个函数，必须配合OVER()子句一起用，并且要显式地指定PARTITION BY和ORDER BY。只有这样，你才能准确无误地拿到每个分组里按时间或ID排序后的第一条记录。否则，你得到的所谓“第一”，很可能是个随机数，结果完全不可控。

MySQL 8.0 中 FIRST_VALUE() 必须配合 OVER() 使用，不能单独求“分组第一条”

很多开发者容易掉进一个坑：直接写个FIRST_VALUE(col)，语法上不报错，但跑出来的结果却让人摸不着头脑。为什么呢？因为如果缺少明确的排序指令，MySQL会默认按它认为的“无序”行来处理，所谓的“第一”就变成了随机抽取。要想真正拿到业务上需要的东西——比如“每个部门里入职最早的那位员工”，你就必须清清楚楚地告诉数据库：按什么分组（PARTITION BY），以及按什么顺序找第一（ORDER BY）。

如果你发现查询出现了下面几种情况，那很可能就是FIRST_VALUE()没写对：
– 同一个查询，每次执行的结果居然不一样。
– 在同一个分组里，FIRST_VALUE(name)返回的不是最早创建的用户名，而是中间某条记录。
– 最经典的，是忘了写PARTITION BY，导致整个表被当成一个组来处理，只返回了一个“第一”。

这里有几个关键点需要牢记：

• FIRST_VALUE()本质上是一个窗口函数，它必须嵌套在SELECT语句里使用，不能直接放到WHERE或GROUP BY这些地方。
• 排序逻辑由你定义：如果想按“创建时间最早”取第一条，就写ORDER BY created_at ASC；如果想按“ID最小”来取，那就是ORDER BY id ASC。
• 分组字段（比如category_id）必须明确写在PARTITION BY category_id里，否则函数就不知道该怎么分组了。

正确写法示例：查每个分类下创建时间最早的用户姓名

我们来个具体的例子。假设有一张users表，字段包括id、name、category_id和created_at。现在要找出每个分类（category_id）下，最早创建的那个用户的名字。

SELECT
  id,
  name,
  category_id,
  created_at,
  FIRST_VALUE(name) OVER (
    PARTITION BY category_id
    ORDER BY created_at ASC, id ASC
  ) AS first_user_in_category
FROM users;

注意看这个ORDER BY子句，除了按created_at ASC排序，我们还加上了id ASC作为第二排序键。这其实是一个很实用的技巧，目的是为了避免当created_at时间戳完全相同时，结果出现不确定性。MySQL 8.0的窗口函数要求ORDER BY子句最好能唯一确定行的顺序，否则“第一”的定义就会变得模糊。

FIRST_VALUE() 和子查询 / ROW_NUMBER() 的性能与语义差异

说到取分组第一条，市面上其实有好几种方法。FIRST_VALUE()只是其中之一，另外两种常见的分别是使用ROW_NUMBER()配合过滤，或者写关联子查询。这三者看起来效果类似，但背后的语义和性能特点大不相同：

• FIRST_VALUE() 是“复制值”：它会在结果集的每一行后面，都附加一个本组第一条记录的name。这非常适合需要保留所有原始数据，同时又要参考每组首项进行比对的场景。
• ROW_NUMBER() = 1 是“筛选行”：通过给每行编号然后过滤出序号为1的行，它最终只返回每个分组的一行数据。这更适合做数据聚合后的取样分析。
• 关联子查询：写法上可能更直观（例如(SELECT name FROM users u2 WHERE u2.category_id = u1.category_id ORDER BY created_at LIMIT 1)），但在MySQL 8.0中，尤其是数据量大的情况下，其性能往往不如优化过的窗口函数，因为子查询可能无法充分利用索引。
• 窗口函数还有一个优势，它天然支持更复杂的排序和“帧”定义（比如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），虽然单纯求“第一条”时通常用不上这些高级特性。

容易被忽略的 NULL 和排序陷阱

最后，聊聊两个容易踩雷的细节。FIRST_VALUE()在处理NULL值时，会老老实实地按照你指定的ORDER BY规则进行排序。在MySQL的默认行为里，NULL值在升序排序（ASC）时会被视为最小，也就是NULLS FIRST。这意味着，如果你的created_at字段允许为空，那么一条创建时间为NULL的记录，很可能被当作“最早”的记录选出来，这显然不是我们想要的。

怎么规避呢？这里有几个思路：

• 最稳妥的办法，是在查询外层或子查询中直接过滤掉空值：WHERE created_at IS NOT NULL。
• 如果你使用的是MySQL 8.0.22及以上版本，可以在ORDER BY子句中显式控制NULL的位置，比如写成ORDER BY created_at ASC NULLS LAST，这样业务上“未填写时间”的记录就会排到最后。
• 另外，当对字符串字段使用FIRST_VALUE()时，也要留意数据库的排序规则（collation），比如大小写是否敏感，这也会直接影响最终的排序结果顺序。

说到底，窗口函数不是一个黑盒子。它返回的“第一”，完全由你写在PARTITION BY和ORDER BY里的条件所定义。少写一个条件，或者理解错一个细节，最终结果就可能和你的业务预期南辕北辙。这一点，务必警惕。