应使用窗口函数SUM() OVER(PARTITION BY)而非GROUP BY，以保留明细行并附加分组汇总值；GROUP BY会压缩行数丢失明细，而窗口函数在不减少行数前提下为每行注入对应分组的聚合结果。
用 GROUP BY + SUM() OVER() 实现明细带总数
直接在明细行上显示分组汇总值，不能只靠 GROUP BY —— 那会把明细“压扁”成一行。正确做法是保留原始行粒度，用窗口函数补上聚合结果。
比如查每个订单的明细，同时显示该订单的总金额：SUM(amount) OVER (PARTITION BY order_id) 就是核心。它按 order_id 分组求和，但不折叠行，每行都带上对应分组的总和。
常见错误是写成 SUM(amount) GROUP BY order_id，结果只剩一条记录，明细全丢了。
-
PARTITION BY字段必须和业务分组逻辑一致（如order_id、user_id），否则总数对不上 - 如果还要按时间排序再累计，加
ORDER BY create_time到OVER子句里，但注意这会变成“累计和”，不是静态分组总数 - MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle 都支持；SQLite 3.25+ 也行，但旧版 MySQL（5.7 及之前）不支持窗口函数，得换思路
MySQL 5.7 或更老版本怎么办
没有窗口函数时，只能用关联子查询或 JOIN 模拟。性能较差，尤其数据量大时明显卡顿。
例如：给每条订单明细补上该订单的总金额，可写成：
SELECT t1.*, t2.total_amount FROM order_items t1 JOIN ( SELECT order_id, SUM(amount) AS total_amount FROM order_items GROUP BY order_id ) t2 ON t1.order_id = t2.order_id;
注意点：
- 子查询必须
GROUP BY和外层关联字段完全一致，否则可能多对多爆炸 - 如果
order_id有 NULL 值，JOIN会丢掉这些行，要用LEFT JOIN并处理 NULL - 索引很重要：
order_items(order_id, amount)联合索引能加速子查询和连接
COUNT(*) OVER(PARTITION BY ...) 显示每组行数
除了求和，计数也常用。比如想看每个用户下了几单，同时保留每单的原始信息，就用 COUNT(*) OVER(PARTITION BY user_id)。
关键区别：
-
COUNT(column)会忽略NULL，而COUNT(*)统计所有行（含NULL字段） - 如果分组字段本身有
NULL，不同数据库处理方式不同：PostgreSQL 把NULL当独立一组，MySQL 8.0 也是；但有些旧版可能跳过，建议显式过滤或用COALESCE(user_id, -1)归一化 - 别写成
COUNT(*) OVER()（没PARTITION BY）—— 那是全表总行数，不是分组数
WHERE 和窗口函数的执行顺序容易搞错
窗口函数在 WHERE 之后、ORDER BY 之前执行。这意味着：先过滤，再算窗口值。
所以如果你加了 WHERE status = 'paid'，那 SUM(amount) OVER(PARTITION BY order_id) 算出来的就是“已支付项”的小计，不是订单原始总额。这点极易被忽略。
- 要统计原始分组总数（不管状态），得把过滤条件挪到子查询或 CTE 里，主查询只做窗口计算
- CTE 写法更清晰：
WITH base AS (SELECT * FROM orders WHERE ...), with_total AS (SELECT *, SUM(...) OVER(...) FROM base) - 别指望在
WHERE里直接引用窗口函数结果（如WHERE total_amount > 100），会报错 —— 必须用外层查询或HAVING（仅限聚合后）
窗口函数的 PARTITION BY 字段是否覆盖全部业务分组维度，以及 WHERE 是否意外截断了分组数据，这两点最常导致总数对不上。动手前先确认原始数据里分组键的分布和空值情况。
