GROUP BY 会压缩明细行是因为其本质是聚合操作，将多行合并为单行统计结果；要保留明细并计算分组值，应使用窗口函数如SUM() OVER(PARTITION BY x)。
GROUP BY 为什么“丢”了明细行
这事儿得从根儿上讲。GROUP BY 的设计初衷就是聚合，它的任务是把多行数据压缩成一行。结果呢？原始的明细信息，比如每笔订单的 order_id、created_at，在最终结果集里自然就“消失”了。你看到的只剩下分组后的统计值，像是 COUNT(*) 或者 SUM(amount)。
所以，这并非系统出了什么差错，而是它本该如此。如果想在保留每一条原始记录的同时，还能看到它所属分组的计算结果，那就得换个思路了：放弃聚合，转向窗口函数。
用 ROW_NUMBER() + 子查询强行“还原”明细
有时候需求比较特殊：既要展示所有原始记录，又希望每条记录旁边能附带它所在组的统计信息（比如，“显示所有订单，并标注该用户总共下了多少单”）。这时候，ROW_NUMBER() 本身虽然不直接做聚合，但配合子查询或者公共表表达式（CTE），就能巧妙地绕过 GROUP BY 对行数的压缩。
- 核心思路是分两步走：先用窗口函数计算出每组的聚合值，这个过程不会减少行数；然后再根据需要进行过滤或排序，例如，用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)来标记出每组中最新的一条记录。 - 需要注意的是，窗口函数的结果不能直接在
WHERE子句里使用，通常需要额外嵌套一层查询（CTE 或子查询）来实现筛选。
来看个具体例子：查询每个用户的首单时间，同时保留所有订单的明细。
SELECT user_id, order_id, amount,
MIN(created_at) OVER (PARTITION BY user_id) AS first_order_time
FROM orders;
SUM / COUNT / A VG 等聚合函数加 OVER 就是窗口版
这才是解决问题的关键。把普通的 SUM(amount) 加上 OVER (PARTITION BY user_id)，魔法就发生了：结果不再是每个用户只有一行汇总数据，而是每一行原始数据都额外带上了一个“该用户总金额”的字段。这正是用窗口函数替代 GROUP BY 来实现分组统计却不丢失明细的核心操作。
COUNT(*) OVER (PARTITION BY x)相当于告诉你“这一组里总共有多少行”，相比GROUP BY x后再COUNT(*)，它完美保留了所有原始字段。- 这里有个细节要注意：如果在窗口定义中加入了
ORDER BY，像SUM() OVER (PARTITION BY x ORDER BY dt)，就会变成累积计算；不加ORDER BY，才是计算整个分区的总和。 - 从支持度来看，MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都提供了完善的支持；甚至 SQLite 从 3.25 版本开始也加入了支持，当然，更旧的版本就不行了。
容易忽略的 NULL 和排序陷阱
窗口函数用起来顺手，但有些坑容易踩。比如对 NULL 值的处理，窗口函数和普通聚合函数可能有所不同：默认情况下，PARTITION BY 会把 NULL 值都归为同一组，但像 PostgreSQL 这样的数据库允许你用 IS NOT DISTINCT FROM 来显式控制。更常见的问题是，排序字段如果包含 NULL，可能会导致 ROW_NUMBER() 的排序结果不稳定。
- 如果
ORDER BY的字段可能为NULL，稳妥的做法是加上NULLS LAST（PostgreSQL/Oracle 支持），或者用COALESCE(dt, '9999-01-01')这样的函数给个默认值。 - MySQL 不支持
NULLS LAST语法，那怎么办呢？可以用ORDER BY col IS NULL, col这种写法来达到类似效果。 - 还有一个初学者常犯的错：如果没写
PARTITION BY，直接使用OVER ()，那就意味着把整张表当作一个组来计算，一不小心就可能算出一个全局总值，这可得留神。
说到底，真正的难点往往不在于语法怎么写对，而在于想清楚业务逻辑：你到底是想“按组查看汇总结果”，还是想“查看每一条明细记录时，同时知道它所属组的汇总情况”？后者，才是窗口函数真正大显身手的场景。
