用over()算每组占比需在sum或count外加窗口函数，并严格指定partition by分组字段；漏写会导致全表占比错误；round应置于最外层且用100.0避免整除；旧版mysql需用子查询join模拟，注意null和笛卡尔积。
怎么用 OVER() 算每组占比，而不是全表占比
直接在 SUM() 或 COUNT() 外套一层窗口函数，但必须把分组条件写进 PARTITION BY，否则默认按全表算。比如要算每个部门的销售额占本部门总销售额的比例，PARTITION BY dept_id 是关键，漏掉就变成“个人销售额 / 全公司总销售额”——结果完全不对。
-
COUNT(*) OVER (PARTITION BY dept_id)得到每人所在部门总人数 -
SUM(sales) OVER (PARTITION BY dept_id)得到每人所在部门总销售额 - 再用当前行的
sales除以上面结果，就是该人在本部门的销售占比
ROUND() 放哪里？为什么经常看到结果是 0.0000000001
浮点数除法在 SQL 里默认精度高但不友好，直接 sales / SUM(sales) OVER (...) 可能产生极小误差，尤其做百分比展示时会多出一串无效小数。必须显式用 ROUND(..., 4) 控制位数，且推荐放在最外层——不是对分子或分母单独 ROUND，那样会引入计算偏差。
- ✅ 正确：
ROUND(sales * 100.0 / SUM(sales) OVER (PARTITION BY dept_id), 2) - ❌ 错误：
ROUND(sales, 2) * 100.0 / ROUND(SUM(sales) OVER (...), 2) - 注意
100.0而非100，避免整数除法截断（尤其在 PostgreSQL、SQL Server 中）
MySQL 8.0 以前没法用窗口函数，替代方案是什么
MySQL 5.7 及更早版本不支持 OVER()，只能靠自连接或子查询模拟，性能差、写法绕。核心思路是：先用子查询算出每组的汇总值，再和原表 JOIN。但要注意关联字段必须能唯一确定分组，否则会爆炸性笛卡尔积。
- 子查询必须带
GROUP BY，且SELECT列只包含分组键和聚合结果（如dept_id, SUM(sales) AS dept_total） -
JOIN条件必须严格匹配分组键，比如ON t1.dept_id = t2.dept_id - 如果分组键有
NULL，多数旧版 MySQL 不会自动匹配，得加OR (t1.dept_id IS NULL AND t2.dept_id IS NULL)
ORDER BY 在 OVER() 里加了，占比结果却不对
ORDER BY 在窗口函数中会触发“累积窗口”，也就是从第一行累加到当前行，不是静态分组总和。想算“本组占比”，OVER(PARTITION BY x ORDER BY y) 是错的；必须去掉 ORDER BY，写成 OVER(PARTITION BY x) 才表示“整个分区的固定总和”。
- 带
ORDER BY→ 累计和（如前 N 名累计销售额） - 不带
ORDER BY→ 全组总和（如本部门所有人销售额之和） - 某些场景需要两者结合（比如“当前行在组内排名 / 组总人数”），那就得用两个独立窗口函数，别混在一个
OVER里
窗口函数本身不难，但 PARTITION BY 和 ORDER BY 的组合效果容易直觉误判；另外老版本兼容方案看似简单，实际在数据量稍大或分组键含空值时，很容易查着查着就卡住或者结果翻倍——这些地方没报错，但结果已经错了。
