SQL窗口函数GROUP BY报错及DISTINCT去重方案合理性咨询

核心原因是SQL的执行顺序决定了GROUP BY会折叠原始行的粒度，窗口函数没法直接引用被折叠的非分组原始列：

• SQL各子句的执行优先级是固定的：FROM/JOIN -> WHERE -> GROUP BY -> 普通聚合计算 -> HAVING -> 窗口函数 -> SELECT DISTINCT -> ORDER BY -> LIMIT
• 第一版代码执行到GROUP BY cus.full_name时，结果集的粒度已经从「每一条租赁合同对应一行」被压缩成了「每一个客户姓名对应一行」，原始表中的rc.penalty字段已经不存在于分组后的结果集里——单个姓名分组下对应多条合同记录，数据库没法确定你要取哪条记录的penalty值传给窗口函数做计算，所以直接抛出标准语法错误。
  不少开发者对窗口函数有误解，以为它不属于聚合逻辑，可以绕开GROUP BY的列引用校验，实际上窗口函数的计算输入是GROUP BY、HAVING执行完之后输出的结果集，根本访问不到被分组操作折叠掉的原始明细列。

这个写法在你当前的极简测试数据下能跑出看起来正确的结果，但不属于通用可靠的方案，存在明确隐患，生产环境不推荐使用，具体问题如下：

• 首先是硬逻辑风险，容易出错误数据。SELECT DISTINCT是按照SELECT列表里的所有字段做全等匹配去重，你当前的SELECT字段里没有加客户唯一主键（cus.id），一旦出现两个不同客户同名、且累计罚金刚好相等的情况（比如两个都叫Siro Aveni的客户，总罚金都是510），DISTINCT会把两条属于不同客户的有效记录误合并成一条，直接导致统计结果少算。
• 其次是性能浪费严重。窗口函数不会改变结果集的行数，JOIN出来多少条明细行，加了窗口函数之后还是多少行：如果一个客户签了1000份租赁合同，数据库会先给这1000行每一行都重复计算一次一模一样的客户总罚金，生成1000行完全重复的结果，再做全量排序去重。数据量上来之后，这种写法的性能会远低于先按客户分组聚合算总罚金、再关联取客户姓名的写法，平白生成大量无效中间数据。
• 最后是可维护性差。DISTINCT本身就是很容易隐藏逻辑问题的语法，其他开发人员接手代码时，看到窗口函数+DISTINCT的组合，很难第一时间判断你是要做客户级汇总，还是不小心写漏了关联条件才导致出现重复行，后续迭代很容易改出bug。

你之前不加DISTINCT返回重复行的本质原因也很简单：窗口函数只做附加计算、不合并行，同一个客户名下有几份合同，就会返回几行挂着相同总罚金值的记录，重复是必然的。

更稳妥的实现方式 #

如果你的需求就是查询累计罚金≥500的客户姓名和对应累计罚金，直接用标准分组聚合即可，逻辑清晰性能更好，还能彻底避免同名冲突：

SELECT
    cus.full_name AS full_name,
    SUM(rc.penalty) AS summary_penalty
FROM customer cus 
JOIN rent_contract rc 
    ON cus.id = rc.customer_id
GROUP BY cus.id, cus.full_name -- 用客户主键分组，从根源避免同名问题
HAVING SUM(rc.penalty) >= 500;

如果你确实需要在保留合同明细行的基础上附加客户累计罚金字段（比如同时展示每笔合同的单额和客户总罚金），那直接去掉GROUP BY和DISTINCT即可，不需要强行做客户级去重。

内容的提问来源于stack exchange，提问作者abeasks