COUNT(*) OVER() 不按GROUP BY分组，因其是窗口函数，直接在WHERE过滤后的原始行集上计算总数，而非分组后结果。

为什么COUNT(*) OVER()不按GROUP BY分组？ COUNT(*) OVER() 的本质是窗口函数，它完全绕过 GROUP BY 的分组逻辑，直接在整个结果集（或指定窗口）上计算。如果你已经写了 GROUP BY，但又想在每组里都显示总行数（不是每组的行数），就必须用这个写法——它和聚合函数 COUNT(*) 是两套机制，不会互相干扰。 常见错误是误写成 COUNT(*) OVER(PARTITION BY ...)，这反而会按某列再分组，得到的是子组计数，不是全局总数。

实操要点：

• 确保 OVER() 里**空括号**，不写任何 PARTITION BY 或 ORDER BY
• 它必须和 SELECT 中的其他字段共存；不能单独放在只有聚合的查询里（否则会报错“窗口函数不能与 GROUP BY 混用”之类）
• 如果用了 WHERE，COUNT(*) OVER() 统计的是过滤后的总行数，不是原表总行数

如何在GROUP BY查询中同时返回每组数据和总行数？ 典型场景：你按 category 分组查平均价格，但报表还要求每行都标出“共XX条记录”。这时不能靠子查询或JOIN，否则性能差、写法冗长。 正确做法是把窗口函数和聚合函数混用：

SELECT
  category,
  AVG(price) AS avg_price,
  COUNT(*) AS group_count,
  COUNT(*) OVER() AS total_count
FROM products
WHERE status = 'active'
GROUP BY category;

注意：COUNT(*) OVER() 在 GROUP BY 后仍有效，且值在每一行都相同（即过滤后总组数？不对——是过滤后总行数！等等，这里要小心）。 关键澄清：上面语句中，COUNT(*) OVER() 统计的是 WHERE 之后、但**尚未被 GROUP BY 压缩**的行数。也就是说，它是满足 WHERE status = 'active' 的原始行数，不是分组后的组数。 如果你真想要“分组后的组数”，得用 COUNT(DISTINCT category) OVER() 或更稳妥地写成子查询。

COUNT(*) OVER() 和子查询实现总行数的性能差异 COUNT(*) OVER() 是单次扫描，数据库优化器通常能把它和主查询合并执行；而子查询方式如 (SELECT COUNT(*) FROM products WHERE status = 'active') 可能触发二次扫描，尤其在没索引或数据量大时明显变慢。 但要注意边界情况：

• PostgreSQL 14+ 和 SQL Server 对这类窗口计数优化较好；MySQL 8.0 支持但早期版本可能退化为临时表
• 如果 OVER() 里加了 ORDER BY 或复杂 RANGE，性能会陡降——这里只要总数，就坚决保持空括号
• 某些 BI 工具（如旧版 Metabase）解析窗口函数不稳定，导出 CSV 时可能报错，需提前验证

容易被忽略的NULL和过滤陷阱 COUNT(*) OVER() 统计所有行，包括 NULL 值字段所在的行——这点和 COUNT(col) OVER() 不同，后者会跳过 col 为 NULL 的行。 更隐蔽的问题是：如果你的 WHERE 条件依赖某个表达式（比如 price > 0），而该字段本身有 NULL，那么 NULL 行既不进结果，也不影响 COUNT(*) OVER() 的值——因为它本来就不在结果集中。 但若你误把条件写进 OVER() 里，比如 COUNT(*) OVER(ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)，虽然效果一样，却增加了语法噪声，还可能误导后续维护者以为你在做滚动统计。 真正该警惕的，是把 COUNT(*) OVER() 和 HAVING 混用——HAVING 发生在分组后，而窗口函数在分组后仍可访问原始行上下文，二者逻辑层级不同，强行组合容易产出非预期结果。