corr不能直接作用于sum()、avg()等聚合结果，因其需行级配对原始数据；必须通过子查询先按业务粒度（如省份、月份）分组生成「指标对」宽表，再对两列计算相关系数。
CORR 不能直接套在 SUM()、AVG() 上，否则报 ORA-00937；必须先用子查询生成「分组→指标对」宽表，再对两列调用 CORR。
为什么 CORR(SUM(x), SUM(y)) 会报错
Oracle 的 CORR 是聚合函数，但它的输入必须是行级原始数值列，不是聚合表达式的结果。写 CORR(SUM(x), SUM(y)) 时，SQL 引擎无法确定分组上下文——SUM() 已经压缩成单值，而 CORR 还需要多对 (xᵢ, yᵢ) 来算协方差。报错 ORA-00937: not a single-group group function 就是这个原因。
常见错误现象：
- 误以为“两个聚合结果也能相关”，实际丢失了配对关系
- 在 GROUP BY 外层直接嵌套
CORR(AVG(a), AVG(b))，同样语法不通过 - 把时间序列指标（如月销售额、月访问量）当成两列原始数据直接喂给
CORR，却忘了它们本该按时间对齐
正确写法：用子查询构造指标对宽表
核心是让每行代表一个分析单元（比如一个省份、一个月份、一个产品类目），并带出两个待分析的数值指标。
示例：算各省份「年均订单数」和「年均客单价」的相关性
SELECT CORR(avg_orders, avg_price) AS corr_coef
FROM (
SELECT province,
AVG(order_count) AS avg_orders,
AVG(unit_price) AS avg_price
FROM sales
GROUP BY province
) t;
关键点：
- 子查询里
GROUP BY province确保每省一行，两指标列同源、同行、同粒度 - 外部
CORR()对整列avg_orders和整列avg_price计算皮尔逊系数 - 若加了多余字段（如同时
GROUP BY province, year），会导致行数膨胀，CORR虽能算，但语义变成“跨年+跨省”的混合相关，通常不是你要的
容易被忽略的数据质量陷阱
CORR 表面简单，但结果异常往往来自隐性数据问题：
- 某列全为相同值（如某省所有
avg_price都是 199.00）→ 标准差为 0 →CORR返回NULL - 子查询中某行的
avg_orders或avg_price是NULL（比如该省无销售记录）→ 整行被跳过，有效样本数减少，可能显著影响系数稳定性 - 传入非数值类型（如
TO_CHAR(sal)）→ 报ORA-00932: inconsistent datatypes，必须显式TO_NUMBER()或确保原始列为 NUMBER/DECIMAL - 日期参与计算（如
CORR(hiredate - DATE'1980-01-01', sal)）可行，但要注意 Oracle 日期减法结果单位是“天”，量纲是否合理需人工判断
Oracle 中 CORR 作为分析函数的用法差异
如果想看每个分组内部的局部相关性（比如每个部门内员工工龄与薪资的相关性），要用 OVER 窗口语法：
SELECT deptno,
CORR(SYSDATE - hiredate, sal) OVER (PARTITION BY deptno) AS corr_by_dept
FROM emp;
注意：
- 这里
CORR不是聚合函数，不压缩行数，每行返回一个值（即该部门所有员工的工龄-薪资相关系数） - 不能混用
GROUP BY和OVER在同一层，否则报错；如需聚合后窗口，得套一层子查询 - 窗口函数模式下，
CORR仍严格按皮尔逊公式计算，不是近似或滑动平均
真正卡住人的从来不是语法，而是没意识到：CORR 的输入必须是「对齐的观测对」，而不是「各自算好的汇总数字」。子查询那层宽表构建，就是强制你把业务逻辑落到可配对的粒度上——这步绕不开，也最常被跳过。
