用 SUM() OVER(PARTITION BY group_col) 计算分组内占比最稳妥，兼容主流数据库；需配合 NULLIF 避免除零、ROUND 控制精度、COALESCE 处理 NULL，避免 GROUP BY 后误用导致逻辑错误。
用 SUM() OVER() 算分组内占比最稳
直接用 SUM() 配合窗口函数，是 SQL 里算“某组内各值占本组多少百分比”的标准解法。它不依赖子查询，也不怕重复聚合，兼容 MySQL 8.0+、PostgreSQL、SQL Server、Oracle、DuckDB 等主流引擎。
常见错误是写成 SUM(col) / SUM(col) GROUP BY group_col —— 这会报错或返回全 1，因为分母没限定在组内；也有人用关联子查询，但性能差、可读性低、嵌套深了容易漏 WHERE 条件。
-
SUM(col) OVER (PARTITION BY group_col)是分母：按组求和，每行值都填入对应组的总和 -
SUM(col) OVER (PARTITION BY group_col ORDER BY ... ROWS UNBOUNDED PRECEDING)是累计占比，不是当前需求，别混 - 如果
col可能为NULL，先用COALESCE(col, 0)，否则整组占比可能变NULL
MySQL 5.7 或旧版 PostgreSQL 怎么办
这些版本不支持窗口函数，只能靠自连接或相关子查询。虽然慢，但能跑通。关键是子查询必须严格匹配外层分组条件，漏一个字段就变成全表占比。
典型错误现象：SELECT a, b, val / (SELECT SUM(val) FROM t AS t2 WHERE t2.a = t.a) 中，如果分组字段是 (a, b)，但子查询只写了 t2.a = t.a，结果就是按 a 汇总，不是你想要的 (a,b) 组内占比。
- 务必核对子查询
WHERE条件字段数和类型，和外层GROUP BY完全一致 - 给子查询加
EXPLAIN看是否走了索引；没索引时，几万行以上就明显卡顿 - 如果只是临时看数，导出后用 Excel 算更省事——别硬扛
ROUND() 放哪？为什么算出来是 0.999999999
浮点精度问题在占比计算里高频出现，尤其当分母是整数、分子是小数，或用了 DECIMAL 但精度定义不足时。不是 bug，是数值表示限制。
不要在除法后才 ROUND()，而应在整个表达式最外层包裹，且明确指定小数位数。否则中间过程截断会放大误差。
- 推荐写法：
ROUND(100.0 * val / NULLIF(SUM(val) OVER (PARTITION BY group_col), 0), 2) -
NULLIF(..., 0)必加，避免除零错误；100.0强制转浮点，防止整数除法（如 MySQL 默认）丢小数 - 如果业务要求“四舍五入后加起来必须等于 100”，那得用“最大余额法”重分配，SQL 原生不支持，得程序层补
GROUP BY 后再算占比？小心逻辑错位
很多人先 GROUP BY 汇总，再想“在这结果上算占比”，但这时原始行已丢失，无法还原分组内构成。除非你本来就要每个组一个占比值（比如“A组销售额占全部销售额比例”），否则这条路走不通。
真实场景中，“每个订单在所属省份的销售额占比”这种需求，必须在明细行上算，不能先按省份汇总再处理。
- 确认你要的是“组内分布”（每行一个占比）还是“组间对比”（每组一个占比）——前者用窗口函数，后者用普通聚合 + 全表和
- 如果误用了
GROUP BY+ 窗口函数，会出现“每组只返回一行，但占比还是按原行算”的混乱结果 - 调试时，先
SELECT *加上窗口和、原始值、占比三列，肉眼对两行数据，比看最终百分比更可靠
事情说清了就结束
