count() over()统计全表总行数，不随group by分组变化；要统计每组行数，必须用count() over(partition by 列)，否则结果与分组无关。
为什么COUNT(*) OVER()不等于GROUP BY的行数？
因为 COUNT(*) OVER() 是窗口函数，它统计的是整个结果集的总行数，不是当前分组内的行数。想统计每个分组内部的记录数，必须配合 PARTITION BY 使用。
- 错误写法：
SELECT name, COUNT(*) OVER() FROM users GROUP BY name→ 返回的是全表总行数，和分组无关 - 正确写法：
SELECT name, COUNT(*) OVER(PARTITION BY name)→ 每个name值对应其出现次数 - 注意：如果用了
GROUP BY，又在 SELECT 里写窗口函数，数据库（如 PostgreSQL、SQL Server）通常允许；但 MySQL 8.0+ 才支持这种混合用法，旧版本会报错
COUNT OVER 和 GROUP BY 能不能一起用？
能，但目的要明确：你是在聚合后加窗口计算，还是在未聚合的原始行上算分组计数。
- 场景一（推荐）：不写
GROUP BY，直接用COUNT(*) OVER(PARTITION BY col)→ 每行都带本组行数，保留原始明细 - 场景二：先
GROUP BY col，再用COUNT(*) OVER()→ 此时窗口函数作用于分组后的结果集，比如统计“有多少个不同的col值” - 示例（统计每种状态的订单数，并标记该状态占全部状态种类的比例）：
SELECT status, COUNT(*) AS cnt,<br> COUNT(*) OVER() AS total_status_kinds<br>FROM orders<br>GROUP BY status;
常见报错：“column must appear in GROUP BY clause”
这是 PostgreSQL / SQLite 等严格模式下的典型错误，发生在你写了 GROUP BY，但 SELECT 里又引用了未分组也未聚合的列，同时还混用了窗口函数。
- 根本原因：窗口函数本身不改变行数，但
GROUP BY会压缩行，两者语义冲突 - 解法1（推荐）：去掉
GROUP BY，用COUNT(*) OVER(PARTITION BY x)+ 其他列直接查询 - 解法2：若必须聚合，就把所有非聚合列放进
GROUP BY，或用MIN()/MAX()包裹（如MAX(name)），再加窗口函数 - 别踩坑：
COUNT(*) OVER(PARTITION BY x) WHERE y > 10是错的——WHERE在窗口计算前执行，不能过滤窗口结果
性能要注意：PARTITION BY 列没索引会很慢
窗口函数的 PARTITION BY 本质是按指定列做逻辑分组，数据库需要扫描并归类数据。如果分区字段基数高（比如用户ID）、且没索引，排序和分组开销会明显上升。
- 查执行计划时注意是否有
WindowAgg节点伴随大块Sort - 优化方式：给
PARTITION BY的列建索引（尤其在大表上） - 替代思路：如果只是要分组总数，且后续不需明细，
GROUP BY + COUNT(*)通常比窗口函数更快、更省内存 - MySQL 用户注意：8.0 以前不支持窗口函数，强行用会报
FUNCTION xxx does not exist
PARTITION BY，后者可能根本不需要窗口函数。
