因为join会将主表一行“撑开”成多行，count(*)统计的是膨胀后的结果集行数而非主表原始记录数；应改用count(从表主键)、count(distinct 关联字段)或先聚合再join来准确计数。
为什么一对多联表后 COUNT() 会重复计数
因为 JOIN 操作会把主表一行“撑开”成多行（比如一个订单关联 3 条订单项，主表该订单就出现 3 次），此时直接 COUNT(*) 或 COUNT(主表字段) 统计的是结果集行数，不是原始主表的记录数。
常见错误现象：SELECT order_id, COUNT(*) FROM orders o JOIN order_items oi ON o.id = oi.order_id GROUP BY order_id —— 这里 COUNT(*) 返回的是每单的子项数，不是“是否下单”的布尔计数；若想统计“每个客户下了几单”，却因 JOIN 导致同一订单被算多次，结果就偏高。
- 根本原因：聚合发生在 JOIN 后的宽表上，而非原始主表粒度
- 不能靠
DISTINCT修复COUNT(DISTINCT order_id)在 GROUP BY 中无效（语法报错或逻辑错） - 窗口函数不改变行数，所以能保留主表原始行结构，再做跨行计算
用 COUNT(DISTINCT) OVER() 解决客户订单数统计
当需要“每个客户名下有多少个不重复订单”，而数据源是客户-订单-订单项三层结构时，必须跳过订单项层对订单数的影响。窗口函数可锚定在客户粒度，只对订单去重计数。
实操写法：
SELECT c.name, o.order_id, COUNT(DISTINCT o.order_id) OVER (PARTITION BY c.id) AS order_count_per_customer FROM customers c JOIN orders o ON c.id = o.customer_id -- 不要 JOIN order_items，否则 partition 内行数膨胀，COUNT(DISTINCT) 仍正确但性能差
- 关键点：
PARTITION BY c.id确保按客户分组，COUNT(DISTINCT o.order_id)在每组内对订单 ID 去重计数 - 如果已 JOIN 到 order_items，需先用子查询或 CTE 把订单层单独聚合好，再和客户 JOIN，避免窗口函数输入行数失控
- 注意：MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle 10g+ 都支持
COUNT(DISTINCT) OVER()；SQLite 和旧版 SQL Server 不支持，得换方案
用 DENSE_RANK() 或 ROW_NUMBER() 标记首次出现解决“首单时间”类问题
类似需求如“每个客户的首单日期”，若用 MIN(o.created_at) 聚合会丢失主表其他字段；若用窗口函数，则可在不压缩行数的前提下打标。
示例：
SELECT
c.name,
o.order_id,
o.created_at,
FIRST_VALUE(o.created_at) OVER (
PARTITION BY c.id ORDER BY o.created_at
) AS first_order_at
FROM customers c
JOIN orders o ON c.id = o.customer_id
-
FIRST_VALUE()是最直白的解法，但注意它不自动去重——如果同一客户有两单同天，可能返回重复时间；需要业务确认是否接受 - 更严格场景可用
ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY o.created_at, o.order_id)找出row_num = 1的那行，再 LEFT JOIN 回原表取值 - 别用
RANK()：遇到并列时会跳过后续序号，导致“第二单”可能变成第 3 行，语义易混淆
容易忽略的性能与语义陷阱
窗口函数不是银弹。一对多联表后直接套窗口，常因中间结果集爆炸引发 OOM 或超慢执行。
- 先检查 JOIN 后的行数膨胀倍数：执行
EXPLAIN或加COUNT(*)看实际扫描行数 - 优先在聚合层收口：比如先
GROUP BY customer_id, order_id汇总每单金额，再用窗口函数算客户维度指标，比在明细层跑窗口快一个数量级 - ORDER BY 在窗口定义中不是可选的——
FIRST_VALUE、LAG等依赖排序；漏写会导致结果非确定（尤其分布式引擎如 Presto/Trino） - PostgreSQL 中
OVER ()默认是整个结果集，但 MySQL 8.0 要求显式写OVER ()才生效，不写等于没开窗口
真正难的不是写出窗口函数，而是判断该不该在 JOIN 后立刻用它——多数情况下，应该先用 GROUP BY 把一对多压回一对，再用窗口处理剩余维度逻辑。
