corr函数必须作用于行级原始列，不能对sum()、avg()等聚合结果再聚合，因其计算依赖成对观测值(xᵢ,yᵢ)求协方差，先聚合会丢失配对关系；正确做法是先用子查询生成“分组→指标对”的宽表，再对两指标列调用corr。
直接用 CORR(col1, col2) 会报错？先确认输入是不是行级原始列
很多人一写 CORR(SUM(revenue), SUM(users)) 就遇到 ORA-00937（Oracle）或语法错误（PostgreSQL/MySQL），根本原因不是函数不会用，而是 CORR 的输入必须是「成对的原始观测值」——比如每一行代表一个日期的 revenue 和 users，而不是先按天聚合再喂给 CORR。
它不接受任何中间聚合结果，因为皮尔逊公式需要每对 (xᵢ, yᵢ) 算协方差，而 SUM() 后只剩单个标量，配对关系彻底丢失。
- ✅ 正确：对原始明细表直接算，如
CORR(sales_amt, advertising_amt)（每行是一笔订单） - ❌ 错误：嵌套聚合，如
CORR(AVG(x), AVG(y))或CORR(SUM(x), COUNT(y)) - ⚠️ 注意：即使你用 CTE 写了
SELECT date, SUM(x) AS x_sum FROM t GROUP BY date，后续在外部再套CORR(x_sum, y_sum)是合法的——但前提是这个 CTE 输出的是「组→指标对」的宽表结构，且没漏掉配对逻辑
想算「省份平均订单数」和「省份平均客单价」的相关性？子查询是必经之路
业务指标天然带分组维度（如省份、月份、渠道），CORR 不能跨组“理解语义”，只能机械地对两列数值序列做全局计算。所以你要先构造出「每个省一行、含两个指标值」的中间结果，再喂给 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是关键，确保输出每行对应一个省的两个指标 - 如果加了多余字段（比如
GROUP BY province, year），那结果变成「每个省每年一行」，CORR 算的是所有年份×省份组合的混合相关性，业务含义可能错乱 - 若某省某指标全为 NULL（如无订单记录），该行整行被跳过，不参与计算——别指望它自动填充或警告
不同数据库对 CORR 的容忍度差异很大，别默认“写法一样结果就一样”
表面都是 CORR(x, y)，但底层处理逻辑和报错边界差别明显，容易导致开发环境 OK、上线后结果异常或报错。
- Oracle / PostgreSQL：支持
OVER()窗口用法，如CORR(x,y) OVER (PARTITION BY region)；要求两列都为数值型，DATE或字符串列必须显式转，否则报ORA-00932或类型不匹配 - MySQL 8.0+：原生不提供
CORR()函数，强行用会报Unknown function 'CORR'；得手写皮尔逊公式展开，或依赖自定义函数（维护成本高，精度难控） - Hive / Spark SQL：接受整数列，但若列中混入
Infinity或NaN，结果直接变NaN，且不提示 - 所有引擎：NULL 处理策略一致——整行剔除，不是单值填充；但 Excel 的
CORREL()会把字符串 "0" 当 0 处理，SQL 一律不认，必须提前清洗
CORR 返回 NULL 或 0 不一定代表无关，先查标准差和有效行数
常见误判：看到 CORR 返回 NULL 就以为数据有问题，其实更可能是数学前提不满足。
-
CORR返回NULL的典型场景：某一列所有值相同（标准差为 0），或两列非 NULL 行数不一致（比如 A 列有 10 行非空，B 列只有 9 行） - 返回接近 0 的值，未必是“不相关”——可能只是线性相关弱，但存在强非线性关系（如抛物线趋势），CORR 捕捉不到
- 建议加辅助检查：在子查询里补充
COUNT(*)、COUNT(col1)、COUNT(col2)，确认有效配对数；用STDDEV_POP(col1)和STDDEV_POP(col2)看是否为 0 - 如果业务上明确要排除异常值（如单日销售额 > 1000 万的 outlier），必须在子查询的
WHERE里过滤，不能靠外部HAVING——后者作用于聚合后，已无法恢复原始配对
