COUNT() OVER() 报错因聚合函数不可嵌套于窗口函数，正确写法是COUNT(1) OVER()或COUNT(id) OVER()；跨库推荐COUNT(id) OVER()，NULL字段需用COUNT()确保全行统计。
为什么 COUNT(*) OVER() 会报错？
直接写 COUNT(*) OVER() 在多数数据库里会触发语法错误，比如 PostgreSQL 报 ERROR: aggregate function calls cannot be nested，MySQL 8.0+ 虽支持但要求必须明确分区或排序上下文。根本原因是 COUNT(*) 是聚合函数，而 OVER() 需要的是窗口函数语义——它不能套在另一个聚合函数外面，必须用不带 GROUP BY 的形式参与计算。
正确做法是改用 COUNT(1) OVER() 或 COUNT(*) OVER()（仅当未出现在 GROUP BY 查询中时），但更稳妥、跨库兼容的方式是：用非空列（如主键）做计数，例如 COUNT(id) OVER()。
- PostgreSQL / SQL Server / Oracle：支持
COUNT(1) OVER()和COUNT(id) OVER() - MySQL 8.0+：支持
COUNT(*) OVER()，但若查询含 GROUP BY，则必须显式写COUNT(*) OVER()而非嵌套在聚合中 - SQLite：不支持窗口函数（截至 3.45 版本）
如何在同一查询里返回总行数 + 每组行数？
典型场景是：查用户订单数据，既要知道「全部订单有多少条」，又要清楚「每个用户下了几单」。这时不能只靠 GROUP BY user_id，否则总行数就丢了；也不能只用子查询，性能差且可读性低。
正确解法是组合两个窗口函数：COUNT(*) OVER() 算总数，COUNT(*) OVER(PARTITION BY user_id) 算分组数。注意：两者必须共存于同一 SELECT 中，且不能有 GROUP BY。
SELECT user_id, order_id, COUNT(*) OVER() AS total_count, COUNT(*) OVER(PARTITION BY user_id) AS user_order_count FROM orders;
- 只要没写
GROUP BY，这个查询就能保留原始行粒度，每行都带总记录数和所属用户的订单数 -
COUNT(*) OVER()等价于COUNT(1) OVER()，但比COUNT(id) OVER()更安全（避免 id 为 NULL 导致漏计） - 如果表很大，窗口函数会触发全表扫描+内存排序，实际执行计划中可能看到
WindowAgg节点，注意监控work_mem（PostgreSQL）或sort_buffer_size（MySQL）
COUNT(column) OVER() 和 COUNT(*) OVER() 有什么区别？
区别关键在 NULL 处理：COUNT(*) 统计所有行，COUNT(column) 只统计该列非 NULL 的行。这在业务字段可能为空时会导致结果偏差。
例如，订单表中 promo_code 字段大量为 NULL，用 COUNT(promo_code) OVER() 就不等于总订单数，而 COUNT(*) OVER() 才是你要的“总记录数”。
- 想统计“有优惠码的订单占总数比例”？用
COUNT(promo_code) OVER()/COUNT(*) OVER() - 想统计“每个品类下有价格的商品数”？用
COUNT(price) OVER(PARTITION BY category)，因为 price 为 NULL 表示无效数据 - 永远别用
COUNT(NULL) OVER()—— 它恒等于 0
在 GROUP BY 查询中还能用 COUNT() OVER() 吗？
可以，但必须理解执行顺序：SQL 先执行 GROUP BY（生成分组结果），再执行窗口函数（在分组后的结果集上计算）。所以 COUNT(*) OVER() 此时统计的是“分组后结果的行数”，不是原始表总行数。
比如对订单按月分组后，COUNT(*) OVER() 返回的是“有多少个月份有订单”，而不是“总共多少订单”。要拿到原始总数，得提前用子查询或 CTE 缓存。
WITH total AS ( SELECT COUNT(*) AS full_count FROM orders ) SELECT YEAR(order_time) AS y, COUNT(*) AS monthly_count, t.full_count FROM orders, total t GROUP BY y;
- 窗口函数在 GROUP BY 之后执行，这是标准 SQL 执行逻辑，不是数据库 bug
- 如果硬要在 GROUP BY 中用窗口函数算原始总数，唯一办法是把原表再 JOIN 一次（不推荐，易引发笛卡尔积）
- CTE 方案最清晰，但要注意 PostgreSQL 对 CTE 的物化行为（
MATERIALIZED默认开启），大数据量时可能多一次扫描
