GROUP BY不能直接获取明细行，因其本质是聚合操作，会将每组多行压缩为单行，丢失原始订单、日志等明细；窗口函数如SUM() OVER(PARTITION BY user_id)则保留所有行，仅附加分组计算值。
为什么不能直接用 GROUP BY 获取明细行
GROUP BY 会压缩数据，每组只返回一行结果，原始的明细行（比如每一笔订单、每一笔日志）就丢了。想统计每组的总数、排名、累计值，同时又保留每一行原始数据，就得换思路——窗口函数就是干这个的。
核心区别：GROUP BY 是“分组聚合后归并”，OVER() 是“分组计算但不归并”，所有输入行都还在。
怎么写一个带 SUM() 的窗口函数代替 GROUP BY 汇总
比如要算每个 user_id 的订单总金额，同时保留每笔订单的 order_id 和 amount：
SELECT order_id, user_id, amount, SUM(amount) OVER (PARTITION BY user_id) AS user_total FROM orders;
注意三点：
-
PARTITION BY user_id对应GROUP BY user_id的分组逻辑，但不删行 -
SUM() OVER返回的是标量值，直接和当前行拼在一起，不是新表 - 没写
ORDER BY在OVER里，说明不关心组内顺序；如果要算“到当前行为止的累计金额”，就得加ORDER BY create_time
RANK() / ROW_NUMBER() 替代 GROUP BY + ORDER BY + LIMIT 1 的常见误用
有人想取每个用户的首单，错误做法是：GROUP BY user_id ORDER BY create_time LIMIT 1 —— 这语法非法，且 GROUP BY 后 SELECT * 也不明确。
正确做法是用窗口函数打序号再过滤：
SELECT order_id, user_id, create_time, amount
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time) AS rn
FROM orders
) t
WHERE rn = 1;
这里容易踩的坑：
- 用
ROW_NUMBER()而不是RANK()：前者严格保证 1,2,3…，后者遇到相同create_time会并列（如 1,1,3），可能漏数据 - 子查询必须起别名（如
t），否则多数数据库报错 -
ORDER BY必须在OVER里，写在外面（如... WHERE rn = 1 ORDER BY user_id）不影响窗口计算顺序
性能和兼容性要注意什么
窗口函数在 PostgreSQL 8.4+、SQL Server 2005+、Oracle 8i+、MySQL 8.0+ 都支持，但 SQLite 和旧版 MySQL 不行。执行时它需要缓存分组内全部数据，内存开销比简单 GROUP BY 大。
如果数据量极大（千万级以上），又只要某几列的聚合值，可以考虑先 GROUP BY 聚合出中间表，再 JOIN 回明细——虽然多一步，但更可控。
真正难的不是语法，而是想清楚：你到底要“按组看趋势”（用窗口），还是“按组出摘要”（用 GROUP BY）。混用或硬套，查出来的结果往往和预期差一截。
