count(1) over()能不group by就返回总数，因为over()定义窗口，空括号表示“所有行作为一个窗口”，count(1)在该窗口内统计行数并为每行返回相同结果；它统计当前查询结果集（受where、join影响）的总行数，与count(*) over()语义性能一致，但需避免count(id) over()（null值被跳过）及旧版sqlite不支持等兼容性问题。
为什么COUNT(1) OVER()能不GROUP BY就返回总数
因为OVER()定义的是窗口，空括号表示“所有行构成一个窗口”，COUNT(1) OVER()不是聚合整张表，而是对当前查询结果集的每一行都填入该窗口的行数——也就是过滤后实际可见的总行数。它和COUNT(*) OVER()语义、性能完全一致，但COUNT(1)写法更明确表达“每行都要知道总数”这个意图。
常见错误：漏写OVER()或误用COUNT(id)
典型报错是：ERROR: column "users.id" must appear in the GROUP BY clause，原因是你写了COUNT(1)却没加OVER()，系统当成传统聚合函数处理了。
- 错例：
SELECT id, name, COUNT(1) FROM users;→ 必须加GROUP BY或改用OVER() - 错例：
COUNT(id) OVER()→ 如果id列允许为NULL，会跳过这些行，总数变少 - 安全写法永远是
COUNT(*) OVER()或COUNT(1) OVER()，二者都不关心字段值
WHERE、JOIN、LIMIT之后还能正确统计吗
能。COUNT(1) OVER()统计的是当前查询逻辑结果集的总行数，不是原表物理行数。它严格受WHERE、JOIN、ORDER BY影响，但不受LIMIT影响——哪怕你只取前10行，COUNT(1) OVER()仍返回满足条件的全部行数。
-
SELECT *, COUNT(1) OVER() FROM orders WHERE status = 'paid';→ 每行显示已支付订单总数 -
SELECT u.name, o.total, COUNT(1) OVER() FROM users u JOIN orders o ON u.id = o.user_id;→ 显示连接后结果集总行数（不是用户数，也不是订单数） -
SELECT * FROM logs ORDER BY created_at DESC LIMIT 100;再加COUNT(1) OVER()？依然返回所有匹配日志的总数，不是100
旧版SQLite或某些PostgreSQL扩展环境容易踩的坑
不是所有数据库都支持窗口函数。SQLite 3.25+才引入OVER()，旧版本执行会直接报错：no such function: COUNT 或 syntax error near "OVER"；PostgreSQL 9.4+完全支持，但如果你在某些只读副本或受限环境中运行，需确认track_counts是否启用（虽不影响语法，但影响统计信息精度）。
- 大数据量时，
COUNT(1) OVER()仍需扫描全部匹配行，无法跳过——它不像索引计数那样“提前终止” - 真正容易被忽略的是：它算的是MVCC可见行数，长事务中可能比
pg_stat_user_tables.n_live_tup略少（因部分新插入行尚未提交） - 如果业务要求“强一致总数”，别依赖系统表估算；如果只是展示分页总数，且能接受几秒延迟，
n_live_tup更快更轻量
