窗口函数不能替代group by，因二者作用层级不同：group by聚合归并行集（输出行数≤输入），over保留原始行结构叠加计算（输出行数=输入）；需压缩行数用group by，需每行附加统计值才用over。
为什么直接用 COUNT() + JOIN 会出错
因为 COUNT() 是聚合函数，一旦和 JOIN 混用又没加 GROUP BY，数据库会报错（如 PostgreSQL 报 column must appear in the GROUP BY clause），而加了 GROUP BY 后又容易把原本想保留的明细行“压缩”掉——比如你本想查每个订单及其用户信息，再附带这个用户的订单总数，但用普通 GROUP BY order_id 就只能统计单条订单，没法算用户总单量。
用窗口函数 COUNT() OVER(PARTITION BY ...) 替代 GROUP BY
窗口函数能在不改变原始行数的前提下做分组统计。关键在于：把要“按什么分组统计”的字段放进 PARTITION BY，而不是 GROUP BY。
- 想统计每个用户的订单总数？写
COUNT(*) OVER(PARTITION BY user_id) - 想统计每个商品被多少不同用户下单过？写
COUNT(DISTINCT user_id) OVER(PARTITION BY product_id)（注意：不是所有数据库都支持DISTINCT在窗口函数里，MySQL 8.0+ 和 PostgreSQL 支持，SQLite 不支持） - 如果关联后出现重复行（比如一个订单有多个商品行），
COUNT(*)会把重复行也计入——这时得先去重或改用COUNT(DISTINCT order_id)
示例（查订单表 orders 关联用户表 users，同时附带该用户的订单总数）：
SELECT o.order_id, o.order_date, u.username, COUNT(*) OVER(PARTITION BY u.user_id) AS user_order_count FROM orders o JOIN users u ON o.user_id = u.user_id;
JOIN 前后放窗口函数的区别很关键
窗口函数执行顺序在 JOIN 之后、WHERE 之前（标准 SQL 执行逻辑）。这意味着：
- 如果在
JOIN后直接写COUNT() OVER(PARTITION BY ...)，统计的是关联后的结果集分组——比如用户表和订单表一对多关联后，一个用户对应 5 行订单，那COUNT(*) OVER(PARTITION BY user_id)就是 5 - 但如果想统计“该用户在原始订单表中有几条记录”，应确保
JOIN不引入额外重复；或者把统计逻辑提前：先用子查询/CTE 算好频次，再JOIN进来（更可控） - 性能上，窗口函数比多次子查询关联通常更快，但若
PARTITION BY字段基数极高（如百万级唯一 ID），排序开销会明显上升
MySQL 5.7 或旧版 PostgreSQL 怎么办
这些版本不支持窗口函数，得用关联子查询模拟：
SELECT o.order_id, o.order_date, u.username, (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = u.user_id) AS user_order_count FROM orders o JOIN users u ON o.user_id = u.user_id;
但要注意：user_id 上必须有索引，否则子查询会变成全表扫描，订单量大时极慢；另外这种写法无法实现 DISTINCT 类统计（比如“该用户买过几个不同商品”），就得靠临时表或应用层补足。
真正麻烦的不是语法，而是搞不清统计口径到底基于哪张表、哪些行——一不留神，user_order_count 算出来是 10，结果发现是因为某订单关联了 10 个商品快照，而不是用户真下了 10 单。
