count(*) over() 返回全表行数，因默认窗口为整表（rows between unbounded preceding and unbounded following）；要分组计数须显式写 partition by。
为什么 COUNT(*) OVER() 会返回全表行数而不是当前分组行数
当你在 SELECT 中写 COUNT(*) OVER() 却发现结果每行都一样，且等于整张表的总行数——这不是 bug，是窗口函数默认行为。OVER() 没带任何子句时，等价于 OVER(ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)，即把整张表当作一个大窗口来统计。
如果你本意是“每组内计数”，必须显式加 PARTITION BY；如果只是想附带总行数，那这个写法反而是对的。
- 想看每组人数？用
COUNT(*) OVER(PARTITION BY dept_id) - 想看全表共多少人？用
COUNT(*) OVER()或COUNT(*) OVER(ORDER BY 1 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - 误写成
COUNT(*) OVER(ORDER BY create_time)会导致逻辑错误：它会按时间排序后做累积计数（从第1行到当前行），不是总数
如何在不改 GROUP BY 的前提下同时返回明细和总计
这是最常见需求：既要看到每个人记录（姓名、部门、薪资），又要附上“公司总人数”“该部门人数”“薪资排名”等聚合信息。传统方案得用子查询或 JOIN，但用窗口函数一行搞定。
关键点在于：窗口函数不破坏原始行数，可与普通列共存于同一 SELECT 中，且无需 GROUP BY。
- 附带公司总人数：
COUNT(*) OVER() AS total_count - 附带部门人数：
COUNT(*) OVER(PARTITION BY dept_id) AS dept_count - 附带部门内薪资倒序排名：
RANK() OVER(PARTITION BY dept_id ORDER BY salary DESC) AS dept_rank - 注意：只要 SELECT 中出现窗口函数，就不能再对非聚合列做
GROUP BY，否则语法报错 —— 这是设计使然，不是限制，是让你换思路
COUNT(*) 和 COUNT(字段) 在 OVER 中的区别
区别和普通聚合函数一致，但在窗口上下文中更容易被忽略：
-
COUNT(*) OVER()统计窗口内所有行，包括NULL行 -
COUNT(salary) OVER()只统计salary IS NOT NULL的行 —— 如果某行salary是NULL，它不会被计入 - 若你统计的是业务主键（如
user_id），一般不会为NULL，两者结果相同；但统计可空字段时务必确认语义 - 性能上无差异，都是扫描一遍窗口数据，但语义错误可能导致报表偏差，比如误把未填薪资的员工也算进“总人数”
MySQL 8.0+ 与 PostgreSQL 的兼容性提醒
虽然语法基本一致，但两个引擎对空窗口或排序的处理有细微差别，容易在线上出问题：
- MySQL 8.0+ 支持完整窗口函数，但
OVER()中省略ORDER BY时，RANGE默认行为可能引发非预期结果（尤其配合SUM等）；COUNT不受影响，但习惯上建议明确写法 - PostgreSQL 允许
OVER(ORDER BY x)不带ROWS子句，默认是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，这对COUNT影响不大，但若后续换成AVG就可能出错 - Oracle 和 SQL Server 同样支持，但旧版本（如 SQL Server 2012+）不支持
OVER()无参数写法，需写成OVER(ORDER BY (SELECT NULL))来模拟
真正容易被忽略的是：当表中存在重复排序键（比如多个员工同一天入职），ORDER BY create_time 配合 RANK() 会产生并列排名，但 COUNT(*) OVER(PARTITION BY dept_id) 不受此影响 —— 它只看分组，不看排序。
