在数据库查询中，一个常见的需求是获取每个分组里的“第一条”记录。比如，你想找出每个部门最早入职的员工，或者每个类别下最新发布的产品。很多人的第一反应是使用 GROUP BY 配合 MIN 函数，但这样做真的能拿到完整的数据行吗？
GROUP BY 后直接用 MIN(id) 的陷阱
一个典型的误解是：SELECT group_col, MIN(id), name FROM tbl GROUP BY group_col 这条语句可以完美地返回每组中 id 最小的那条完整记录。实际上，这行不通。
问题出在 name 这个字段上。根据 SQL 标准，在 GROUP BY 子句之后，任何没有用聚合函数（如 MIN, MAX, SUM）包裹的非分组列，其语义都是不明确的。数据库引擎无法保证你查出来的这个 name 值，就一定来自 MIN(id) 所在的那一行。在 MySQL 5.7 及之后的版本中，这种写法默认会报错。而在一些旧版本中，它可能返回一个随机的、不确定的值，这无疑是数据准确性的噩梦。
首选方案：使用窗口函数 ROW_NUMBER()
要清晰、可靠地获取每组的第一条记录，窗口函数是目前最优雅和强大的解决方案。它在 PostgreSQL、SQL Server、Oracle 以及 MySQL 8.0+ 中都得到了良好支持。
SELECT id, group_col, name, value
FROM (
SELECT id, group_col, name, value,
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY id) AS rn
FROM tbl
) t
WHERE rn = 1;
这个写法的逻辑非常直观：
PARTITION BY group_col：这定义了我们的分组维度，相当于GROUP BY group_col。ORDER BY id：这决定了“第一条”是按什么标准来选的。如果你想按创建时间取最早记录，换成ORDER BY created_at即可。- 最后，在外层查询中筛选出编号
rn = 1的行，这就是每个分组里的“首行”。
需要注意的是，ROW_NUMBER() 函数会为每一行分配一个唯一的序号，即使 id 相同也不例外。如果存在并列情况（比如两条记录 id 相同），并且你希望它们都视为“第一”，可以考虑使用 RANK() 或 DENSE_RANK() 函数，但这两种函数在出现并列时的具体行为略有不同。
兼容方案：关联子查询
如果你的数据库环境还不支持窗口函数（例如 MySQL 5.7 或更早版本），关联子查询是一个可靠的备选方案。其思路是分两步走：先找出每个分组的最小 id，再通过关联回原表来获取完整的行数据。
SELECT t1.* FROM tbl t1 INNER JOIN ( SELECT group_col, MIN(id) AS min_id FROM tbl GROUP BY group_col ) t2 ON t1.group_col = t2.group_col AND t1.id = t2.min_id;
采用这种方法时，有几个细节需要留心：
- 唯一性陷阱：如果
group_col和id的组合不能唯一确定一行（例如，同一个组内存在两个相同的id），那么这个查询可能会返回多行数据。 - 性能考量：当子查询的结果集很大时，关联操作的性能可能不如窗口函数高效。一个有效的优化手段是为
(group_col, id)建立联合索引。 - 常见错误：不要试图简化为
WHERE id IN (SELECT MIN(id) ...)。这种写法丢失了分组字段的关联条件，会导致跨组匹配，结果完全错误。
为什么不推荐 GROUP BY ... LIMIT 1？
可能有人会想，能不能用 GROUP BY ... ORDER BY id LIMIT 1 这种写法？答案是：强烈不推荐，并且在绝大多数数据库里，这要么是语法错误，要么是逻辑错误。
LIMIT 子句作用于整个查询的最终结果集，而不是每个分组内部。这意味着你只能拿到全局的第一条记录，而不是每个组的第一条。虽然某些旧版本的 MySQL 可能允许这种语法，但其行为是不可预测、不可靠的。在 PostgreSQL 和 SQL Server 中，这类查询会直接报错。因此，不要依赖这种有缺陷的写法。
说到底，要准确获取“每组第一条”记录，核心逻辑必须清晰：一是明确定义分组依据（使用 PARTITION BY 或子查询中的 GROUP BY），二是明确定义“第一”的排序规则（使用 ORDER BY）。缺少其中任何一个环节，查询结果就失去了确定性，变得不可控。
