正确解法是用 COUNT() OVER(PARTITION BY ...) 替代 COUNT() + JOIN，因后者因行膨胀导致统计失真；窗口函数在 JOIN 后执行，需确保 PARTITION BY 字段准确反映业务分组逻辑。
直接用 COUNT() 或 SUM() 配合 JOIN 必然出错或结果失真——因为聚合函数和多行关联天然冲突。正确解法是把统计逻辑从 GROUP BY 挪到窗口函数里，用 PARTITION BY 定义分组维度，不压缩行，只附加值。
为什么 COUNT(*) + JOIN 会报错或翻倍？
错误不是语法问题，而是语义矛盾：COUNT(*) 是聚合函数，数据库要求所有非聚合字段必须出现在 GROUP BY 中（如 PostgreSQL 报 column must appear in the GROUP BY clause）；而加了 GROUP BY order_id 后，原本想保留的用户信息、商品明细等就被压成单行，明细丢失。
- JOIN 后行数膨胀（比如 1 个订单关联 3 条明细，就变 3 行），
COUNT(*)自然算出 3，而非原始订单数 1 -
GROUP BY强制折叠，无法同时返回“每条明细”和“该用户总订单数”两层信息 - 子查询先聚合再
JOIN虽可行，但易漏数据（如LEFT JOIN变INNER JOIN）、性能差、嵌套深
COUNT() OVER(PARTITION BY ...) 是最简替代方案
它不做任何行合并，只在每行上“贴”一个统计值。关键在 PARTITION BY 字段必须是你想按之分组统计的业务主键，比如用户 ID、商品 ID、日期等。
- 统计每个用户的订单总数：
COUNT(*) OVER(PARTITION BY user_id) - 统计每个商品被多少不同用户买过（MySQL 8.0+/PostgreSQL 支持）：
COUNT(DISTINCT user_id) OVER(PARTITION BY product_id) - 如果关联后出现重复（如订单表 × 明细表），
COUNT(*)会把重复行也计入——此时应改用COUNT(DISTINCT order_id)，或提前在子查询中去重 - 别漏写
PARTITION BY：写成COUNT(*) OVER()就变成全表总数，所有行都一样
JOIN 前后放窗口函数，结果可能完全不同
窗口函数执行顺序在 JOIN 之后、WHERE 之前。这意味着它统计的是关联后的中间结果集，不是原始单表数据。
- 如果你查
orders JOIN users，再写COUNT(*) OVER(PARTITION BY user_id)，算的是“这个用户在关联结果里有多少行”——若该用户有 5 条订单且每单有 2 条明细，结果就是 10 - 想统计“该用户在 orders 表里原始有多少订单”，就得先在 orders 表里用 CTE 或子查询算好频次，再
JOIN进来，更可控 - 某些场景可用
FIRST_VALUE()或MAX()窗口函数把聚合值“广播”回来，避免二次 JOIN，例如：FIRST_VALUE(order_total) OVER(PARTITION BY order_id)可把预计算的订单总额带入明细行
性能与兼容性必须提前检查
窗口函数不是银弹。PARTITION BY 字段若无索引、基数又高（比如千万级唯一 ID），排序开销会陡增；老版本数据库可能根本不支持。
- 执行
SELECT SUM(1) OVER ()测试是否支持基础窗口函数：MySQL 5.7 不行，8.0+ 可以；SQLite 需 3.25.0+；PostgreSQL 8.4+ 全支持 - 性能瓶颈常藏在执行计划里的
Sort节点——给PARTITION BY和ORDER BY字段建联合索引（如(user_id, created_at)），能显著减少排序成本 - 注意 NULL：部分数据库把 NULL 当作独立分组，导致统计偏差；必要时用
COALESCE(user_id, -1)统一处理
真正容易被忽略的，是窗口函数的“执行时机”——它永远作用于当前 SQL 阶段已生成的行集。JOIN、WHERE、GROUP BY 的顺序稍一变动，PARTITION BY 算出来的结果就可能完全不是你想要的业务含义。
