COUNT(*) OVER() 能替代子查询，因它在WHERE过滤后的结果集上一次性计数并广播至每行，仅扫描一次；而子查询需重复扫描同一谓词，效率更低。
直接用 COUNT(*) OVER() 就能绕过子查询，前提是你要统计的是当前查询结果集的总行数，而不是原表全量行数。
为什么 COUNT(*) OVER() 能替代子查询
传统写法如 SELECT *, (SELECT COUNT(*) FROM t WHERE status = 'active') AS total FROM t WHERE status = 'active' 会让数据库对同一过滤条件执行两次扫描：一次取明细，一次算总数。而 COUNT(*) OVER() 在窗口内一次性完成计数，并把结果广播到每一行，逻辑等价但物理上只扫一遍。
- 它不改变结果集行数，也不压缩数据，只是“附加工具列”
- WHERE 条件已生效后，
OVER()统计的就是这个过滤后的结果集行数 - 比起关联子查询或派生表，它省掉一次独立执行计划，避免重复谓词评估
COUNT(1) OVER() 和 COUNT(*) OVER() 有区别吗
没有实质区别。两者在所有主流引擎（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）中行为一致：都统计非 NULL 行——而 1 永远非 NULL，* 表示整行存在性，效果相同。
- 别写
COUNT(id) OVER()：如果id允许为 NULL，会漏计 - 旧版 SQLite（near "OVER": syntax error
- 某些 ORM 自动生成 SQL 时可能误删
OVER()，导致退化成聚合报错：column must appear in GROUP BY
哪些场景下它反而更慢
空括号 OVER() 在 PostgreSQL 和 SQL Server 中会触发隐式全局排序，哪怕你只想要一个总数。优化器无法跳过排序步骤，尤其当结果集大且无索引支撑时，比单独查 SELECT COUNT(*) FROM ... 再 JOIN 还慢。
- 如果只是需要总数列且后续不参与排序/分页，优先用两步：先
SELECT COUNT(*)得总数，再用应用层或 JOIN 注入 - 多个不同
OVER共存（比如同时有COUNT(*) OVER()和ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)），引擎大概率分别排序，不复用中间结果 - 加了
LIMIT后，COUNT(*) OVER()仍返回真实匹配行数，不是 LIMIT 值——这点容易被误读，但它本身没错，只是语义和直觉不符
真正要注意的不是语法能不能写，而是你是否清楚 OVER() 统计的是哪一层的结果集，以及数据库到底为此多做了多少排序和内存分配。
