应使用窗口函数COUNT(*) OVER (PARTITION BY group_col)获取分组总行数，并配合SUM(CASE WHEN type='A' THEN 1 ELSE 0 END)计算分子，避免NULL干扰；占比结果保留小数形式，筛选须用HAVING而非WHERE。
GROUP BY 后怎么算每个分组里某字段的占比
直接用 COUNT() 除以分组总行数就行，但别手写两次 COUNT(*) —— 容易错且难维护。核心是用窗口函数 COUNT(*) OVER (PARTITION BY ...) 先拿到分组总数，再和当前行的业务类型计数做除法。
- 错误写法：
COUNT(CASE WHEN type='A' THEN 1 END) / COUNT(*)看似合理，但若分组内有 NULL 的type，COUNT(*)会包含它，而COUNT(CASE...)不会，结果偏小 - 推荐写法：先用
COUNT(*) OVER (PARTITION BY group_col)得到每组总行数，再配合SUM(CASE WHEN type='A' THEN 1 ELSE 0 END)算分子，避免 NULL 干扰 - 注意：MySQL 8.0+、PostgreSQL、SQL Server 2005+、Oracle 都支持窗口函数；SQLite 3.25+ 也支持，但旧版不支持
用 SUM + CASE 还是 COUNT + CASE 计算子类数量
COUNT(CASE WHEN ... THEN 1 END) 和 SUM(CASE WHEN ... THEN 1 ELSE 0 END) 表面结果一样，但行为不同：前者跳过 NULL，后者强制补 0，语义更清晰、抗干扰更强。
- 如果
type列允许为 NULL，COUNT(CASE WHEN type='A' THEN 1 END)对 NULL 行完全忽略，连“0 占比”都不会体现 -
SUM(CASE WHEN type='A' THEN 1 ELSE 0 END)明确把每行都纳入计算，NULL 行贡献 0，和业务直觉一致 - 性能上无差异，但可读性和健壮性上
SUM + ELSE 0更稳
百分比结果是小数还是带%符号的字符串
数据库里存/算占比，一律用小数（如 0.372），别转成字符串加 %。格式化交给应用层或报表工具。
- 在 SQL 里拼
CONCAT(ROUND(..., 2), '%')看着方便，但后续没法参与数值计算、排序、条件过滤 - 用
ROUND(CAST(SUM(...) AS FLOAT) / COUNT(*) OVER (...), 4)保持数值类型，小数位按需控制 - 某些数据库（如 PostgreSQL）对整数除法默认截断，记得显式转
FLOAT或乘1.0
WHERE 和 HAVING 对占比计算的影响顺序
想筛出“某业务类型占比超 30% 的分组”，必须用 HAVING，不能写在 WHERE。因为占比是分组后才有的值，WHERE 发生在分组前。
-
WHERE type IN ('A','B')是预过滤原始数据，会影响分母（分组总行数） -
HAVING SUM(CASE WHEN type='A' THEN 1 ELSE 0 END) * 1.0 / COUNT(*) > 0.3才是对分组结果的筛选 - 常见坑：把占比条件写进
WHERE，报错或返回空——因为聚合列无法在WHERE中引用
事情说清了就结束。真正麻烦的是 NULL 处理和分母来源，这两个点一错，占比就失真，而且不容易被肉眼发现。
