count() over() 返回原表每行对应的分组总数而非聚合后单行结果，因它是升维计算，行数不变；需显式写partition by，order by对纯计数无效。
为什么 COUNT() OVER() 返回的不是分组总数？
常见错觉是 COUNT() OVER(PARTITION BY col) 会像 GROUP BY 那样只返回每个分组一行结果——其实它是在**原表每一行上补一个统计值**，行数完全不变。如果你看到每行都显示“1”，大概率是漏写了 PARTITION BY，变成了全表计数（或窗口未定义导致默认行为）。
正确用法必须显式指定分区，比如按用户ID分组统计该用户总订单数：
SELECT user_id, order_id,
COUNT(*) OVER(PARTITION BY user_id) AS user_order_count
FROM orders;
这会在每条订单记录旁附上该 user_id 对应的总订单数，不是聚合后的一行结果。
COUNT(*) OVER() vs COUNT(*) GROUP BY 的核心区别
两者目的不同：COUNT(*) GROUP BY 是降维聚合，输出行数 ≤ 原表；COUNT(*) OVER() 是升维计算，输出行数 = 原表，保留所有原始字段。
- 需要保留明细数据（如查出每个用户的最新订单+该用户总订单数），必须用
OVER() - 只需分组汇总报表（如“各城市订单量”），用
GROUP BY更高效、语义更清晰 -
OVER()可叠加其他窗口函数（如ROW_NUMBER()），GROUP BY不行 - 性能上，
OVER()在大数据量时可能比等价的JOIN子查询略快，但需注意数据库优化器是否支持物化窗口
容易被忽略的 NULL 和空分组问题
PARTITION BY 字段为 NULL 时，所有 NULL 值会被归入同一个隐式分组——这点和 GROUP BY 一致，但常被误认为“没统计进去”。如果业务上 user_id IS NULL 表示匿名订单，而你只想统计已登录用户，就得提前过滤：
SELECT user_id, order_id,
COUNT(*) OVER(PARTITION BY user_id) AS user_order_count
FROM orders
WHERE user_id IS NOT NULL;
另外，空分组（即 PARTITION BY 后无匹配行）不会产生结果，这点和 LEFT JOIN 不同——窗口函数不“补行”，只在已有行上计算。
ORDER BY 在 COUNT() OVER() 中有没有用？
对纯计数来说，ORDER BY 在 OVER() 里**完全无效**。因为 COUNT(*) 不依赖顺序，加了也白加：
-- ❌ 这里的 ORDER BY 不影响结果 COUNT(*) OVER(PARTITION BY user_id ORDER BY created_at)
只有配合 ROWS BETWEEN 或 RANGE 定义滑动窗口时，ORDER BY 才有意义（比如算“截至当前行的累计订单数”）。但那是 SUM() OVER() 或 ROW_NUMBER() 的场景，不是 COUNT(*) 的常规用法。
真正容易卡住的地方是：你以为加了 ORDER BY 就能控制分组内行序来影响计数，其实不能——计数永远是整个分组的总行数，跟顺序无关。
