怎么写才能确保取到每个分组的真正第一条

语法会写只是第一步，关键在于如何定义“第一条”。这里的玄机，几乎全藏在ORDER BY子句里。

常见的误区是，直接按业务时间字段排序，比如ORDER BY created_at。但你想过没有，如果业务上存在数据补录或时间修正，这个created_at还能代表真实的“第一条”吗？很可能，你真正需要的是物理插入顺序的第一条，也就是自增id最小的那条。所以，排序字段的选择，直接决定了结果的语义。

• 明确排序依据：ORDER BY后面跟的字段，必须在分组内能无歧义地定义“第一”。时间戳、自增ID、或是某个序列值，选哪个取决于业务逻辑。
• 指定完整窗口范围：强烈建议加上ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING。这能确保函数审视的是整个分组的所有行，避免默认帧范围带来的意外结果。
• 处理并列情况：如果排序字段可能存在重复值（比如同一秒创建的多条记录），就需要引入次级排序字段来打破平局，例如ORDER BY created_at, id。

来看一个具体例子，目标是取出每个商品类别中价格最高的那个商品名称：

SELECT category,
       FIRST_VALUE(name) OVER (
         PARTITION BY category
         ORDER BY price DESC, id
         ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
       ) AS top_name
FROM products;

这里按价格降序排，价格相同则按id排，确保了结果的唯一性和确定性。

替代方案：当数据库不支持窗口函数时怎么硬解

如果你的生产环境还停留在MySQL 5.7或旧版本的PostgreSQL，窗口函数这条路就走不通了。这时候，就得回归传统SQL技巧来“曲线救国”。

最直观的思路是使用子查询或GROUP BY配合JOIN。但这里坑不少：用子查询找最小ID时，如果不加LIMIT 1且排序字段不唯一，可能会返回多行导致错误；而先聚合再连接的方法，在数据量增大时，性能下降会非常明显。

• 相对安全的写法：分两步走。先用一个聚合查询找出每个分组的锚点（比如最小ID），再用这个结果集去关联原表获取完整数据。SELECT p.* FROM products p JOIN (SELECT category, MIN(id) AS first_id FROM products GROUP BY category) t ON p.id = t.first_id
• 务必避开的性能陷阱：避免使用相关子查询，例如在WHERE条件里嵌套一个按分组排序取第一条的查询。这种写法逻辑清晰，但执行时会对每一行外部查询都执行一次子查询，数据量稍大就会成为性能灾难。
• SQLite用户的特别提醒：SQLite从3.25版本开始支持窗口函数，但有时可能需要特定的编译选项。如果可用，用ROW_NUMBER() OVER (...)=1是更现代的选择。

容易被忽略的NULL陷阱和类型隐式转换

函数用对了，排序也明确了，是不是就高枕无忧了？还早。一些隐蔽的细节同样能让你前功尽弃。

首先是NULL值。FIRST_VALUE函数在遇到整个分组所有值都是NULL时，会老实返回NULL。这听起来合理，但要注意它和MIN()、MAX()等聚合函数在空集上行为的微妙区别。更大的麻烦来自数据类型。想象一下，如果你对一个DECIMAL类型的价格字段使用FIRST_VALUE，但窗口内混入了NULL或经过隐式转换的计算值，最终结果的精度可能会意外丢失。

• 字符串排序规则：对文本字段排序时，数据库的排序规则（Collation）至关重要。大小写是否敏感、是否区分重音，都会影响“第一条”的归属。确保你的ORDER BY语义符合预期。
• 数据库特性差异：在SQL Server中，FIRST_VALUE对datetime2这类高精度时间类型能完好保留精度，但客户端工具显示时可能会截断，别误以为是函数出了问题。而在PostgreSQL里，如果你希望NULL值排在前面，必须显式使用NULLS FIRST，因为默认是NULLS LAST。

说到底，技术实现从来不是最难的。真正的挑战在于，你如何确保自己定义的“第一条”，在数据库的每一次执行、在业务逻辑的每一个环节、在团队成员的共同理解中，都指向同一行数据。时间戳的精度、服务器时区、缺失索引导致的排序不稳定……这些因素都可能让结果在不知不觉中发生变化。精准，源于对每一个细节的掌控。