帕累托二八分析在sql中指按指标降序排列后计算动态累计占比，首次≥80%的分组即属关键20%，须用sum() over (order by ... desc rows unbounded preceding)确保有序累计，而非简单取前20%行数或静态总和除法。
什么是帕累托二八分析在SQL里的实际含义
帕累托二八分析不是简单地取前20%的行，而是按某个指标（如销售额）降序累计占比，找出累计和首次 ≥ 80% 的那个边界点——这个边界可能落在第17行、也可能在第23行，取决于数据分布。窗口函数是唯一能在线性扫描中同时完成排序、累计、占比计算的机制，SUM() OVER 和 ROW_NUMBER() OVER 是核心，但仅靠它们还不够。
必须用 SUM() OVER (ORDER BY ...) 而不能用 SUM() OVER ()
错误做法是先算总和再除，比如 SUM(sales) / (SELECT SUM(sales) FROM t) —— 这无法保证累计顺序，会导致占比错位。正确路径是让累计和与当前行严格对齐：
-
SUM(sales) OVER (ORDER BY sales DESC ROWS UNBOUNDED PRECEDING)：强制按销售额倒序逐行累加 - 必须显式写
ROWS UNBOUNDED PRECEDING，否则某些数据库（如 PostgreSQL 13 之前）默认行为不一致 - 如果排序字段有重复值（比如多个客户销售额都是 1000），
ORDER BY sales DESC会产生不确定的累计顺序，建议补上唯一键：ORDER BY sales DESC, customer_id
如何定位“二八分界线”并标记每行是否属于头部20%
不能用 WHERE 直接过滤累计占比 ≥ 0.8 的行——那会漏掉刚好跨过80%阈值的那一行。正确逻辑是：先算出最小的 row_num 满足 cumsum / total >= 0.8，再用这个 row_num 去广播标记。
- 用子查询或 CTE 先算
total_sales和累计占比，再用MIN(CASE WHEN cum_pct >= 0.8 THEN rn END)提取临界行号 - 主查询里用
rn 判断是否属于帕累托头部，避免浮点误差导致 0.79999999 被排除 - 示例片段：
SELECT *, CASE WHEN rn = 0.8) THEN 'TOP_20%' ELSE 'OTHER' END AS pareto_group FROM ranked;
多维度（如按地区+产品线）做帕累托时最容易踩的坑
多维度 ≠ 简单加 PARTITION BY region, product_line。帕累托分析本质是全局排序下的累计占比，分区后每个组独立计算，结果是“每个地区各自前20%”，而非“全国销售额前20%里各地区的分布”。要真做跨维度帕累托，得先聚合到原子粒度（如客户×产品），再整体排序。
- 若目标是“找出贡献全国80%销售额的 top 客户”，就不要
PARTITION BY，直接全表排序 - 若目标是“每个地区内自己的二八客户”，才用
PARTITION BY region，但注意ORDER BY必须在分区内部有效 -
ROWS UNBOUNDED PRECEDING在PARTITION BY下自动重置，这点很关键，别误以为要手动 reset - MySQL 8.0+ 支持窗口函数，但不支持
PERCENT_RANK()直接替代累计占比，因为PERCENT_RANK()是基于排名而非实际权重
cum_pct = 0.8 做判断，一律用 >= 0.8 并配合 MIN() 提取首行位置。
