SQL中需手动计算偏度和峰度：先用AVG和STDDEV_POP求均值μ与标准差σ，再通过窗口函数广播μ、σ，计算三/四阶中心矩并归一化；注意σ=0拦截、超额峰度校正及性能优化。
SQL里没有现成的SKEWNESS或KURTOSIS聚合函数怎么办
绝大多数SQL引擎（如PostgreSQL、MySQL、SQLite）原生不支持偏度（skewness）和峰度（kurtosis）的聚合计算。想在GROUP BY后直接得到每组的偏度/峰度，必须手动展开三阶/四阶中心矩公式——不是调个函数的事，而是要稳住均值、方差、三阶四阶中心矩这四个中间量，再组合出结果。
用AVG()和POWER()手算三阶中心矩并归一化得偏度
偏度公式为：skew = E[(X−μ)³] / σ³，其中μ是均值，σ是标准差。关键点在于：不能先GROUP BY再对每组单独算三次幂——那样会丢失组内单条记录的原始值，无法准确求和。
实操建议：
- 必须在一个子查询或CTE中，先用
AVG(x)和STDDEV_POP(x)算出每组的μ和σ - 再用窗口函数或自连接把
μ和σ广播回每行，计算POWER(x - μ, 3)并AVG()得三阶中心矩 - 最终除以
POWER(σ, 3)；注意σ = 0时要CASE拦截，否则除零报错 - PostgreSQL可直接用
POWER(x - AVG(x) OVER (PARTITION BY g), 3)，MySQL 8.0+支持类似写法；旧版MySQL需两层子查询模拟
峰度计算要区分EXCESS KURTOSIS还是RAW KURTOSIS
很多统计工具（如Python的scipy.stats.kurtosis）默认返回“超额峰度”（减去3），而SQL手算出来的是原始峰度（E[(X−μ)⁴] / σ⁴）。若你对比Python结果发现总是大3，就是这个原因。
实操要点：
- 四阶中心矩计算逻辑同三阶，只是把
POWER(..., 3)换成POWER(..., 4) - 务必确认业务需求：金融风控常看超额峰度（判断尾部厚度是否异常），而理论推导多用原始峰度
- 当组内样本数
n 时，峰度估计极不稳定，建议加<code>HAVING COUNT(*) >= 5过滤 - 某些引擎（如BigQuery）对
POWER(x, 4)在大数值下易溢出，可先用SAFE_*()函数兜底
性能瓶颈常卡在重复扫描与高次幂计算上
一次分组偏度+峰度查询，底层可能扫描表3–4遍（均值、方差、三阶、四阶各一遍），尤其在没索引的分组字段上，延迟会陡增。
优化方向：
- 把原始数据预聚合到物化视图或临时表，只存
g, n, sum_x, sum_x2, sum_x3, sum_x4六列，后续计算全靠这六项代入公式 - 避免在
SELECT里反复写AVG(x)——它每次都会重算，应提取为CTE列 - PostgreSQL可用
STATS_MODE()等扩展包加速，但跨数据库可移植性差；纯SQL方案反而更稳 - 如果只是做探索性分析，优先用
LIMIT 10000抽样计算，别硬扛全量
真正麻烦的不是公式写不对，而是忘了分组后STDDEV_POP和STDDEV_SAMP的区别，或者在POWER(x - μ, 4)里漏了括号导致运算顺序错乱——这种错误查起来特别费时间。
