正确计算组内占比需先用SUM() OVER(PARTITION BY ...)求组总和，再用当前行值除以该总和，并用CASE WHEN处理除零和NULL，推荐CTE预计算分母以提升可读性与兼容性。
用 SUM() OVER() 计算组内总和再做除法
窗口函数本身不直接提供“占比”功能，必须手动组合：先用 SUM() OVER(PARTITION BY ...) 算出每组的总和，再用当前行值除以该总和。注意不能直接写 SUM(col) / SUM(col) OVER(...) 而不加 PARTITION BY，否则会算全表总和，导致组内占比失真。
常见错误是漏掉 PARTITION BY 或写错分组字段，结果看起来像在“随机归一化”。比如按部门统计销售额占比，却忘了加 PARTITION BY dept，所有人的占比都基于全公司总销售额计算，完全偏离业务含义。
- 确保
OVER()中的PARTITION BY字段与业务分组逻辑严格一致 - 被除数（分子）必须是当前行原始值，不是聚合结果；分母必须是同组的窗口聚合结果
- 如果分子为
NULL，整行占比会变成NULL，必要时用COALESCE(col, 0)防止中断计算
处理除零错误：CASE WHEN 必须包裹除法
当某组总和为 0（例如全组销售额都是 0 或 NULL），直接除会导致 SQL 报错或返回 NULL（行为因数据库而异：PostgreSQL 报错，MySQL 返回 NULL，SQL Server 可能报除零异常）。不能依赖外部过滤，必须在 SELECT 表达式里用 CASE WHEN 拦截。
示例写法：CASE WHEN SUM(sales) OVER(PARTITION BY dept) = 0 THEN 0 ELSE sales * 1.0 / SUM(sales) OVER(PARTITION BY dept) END。注意乘 1.0 是为避免整数除法截断（尤其在 PostgreSQL 和 SQL Server 中）。
- 判断条件必须用窗口函数结果（
SUM(...) OVER(...)），不能用原字段sales - 分支返回值类型要一致，推荐统一用
DECIMAL或带小数的数值类型 - 不要用
NULLIF()替代CASE，它只解决 NULL 但不防 0
性能敏感场景：避免重复写相同窗口函数
同一个查询里多次出现 SUM(col) OVER(PARTITION BY x)，多数数据库（如 PostgreSQL、Oracle）会自动复用计算结果；但 MySQL 8.0 早期版本、某些执行计划下仍可能重复计算，拖慢大表查询。更稳妥的做法是用 CTE 或子查询提前算好分母。
例如先在 CTE 中生成 dept_total 列，主查询直接引用，既清晰又可控：
WITH t AS (
SELECT dept, sales, SUM(sales) OVER(PARTITION BY dept) AS dept_total
FROM orders
)
SELECT dept, sales,
CASE WHEN dept_total = 0 THEN 0 ELSE sales * 1.0 / dept_total END AS ratio
FROM t;
- CTE 方式对可读性和调试友好，尤其当分母逻辑变复杂（比如加 WHERE 过滤后再求和）时
- 若用子查询，注意别名作用域，避免外层查不到窗口列
- 不建议为省一行代码把窗口函数复制三遍——可维护性代价远高于多敲几个字
兼容性差异：ROUND() 的精度陷阱
业务常要求保留两位小数，但 ROUND(ratio, 2) 在不同数据库中行为不一：SQL Server 默认四舍五入，而某些版本的 MySQL 对浮点中间结果有隐式截断。更稳妥的是先转成定点数再四舍五入，比如 ROUND(ratio::DECIMAL(5,4), 2)（PostgreSQL）或 ROUND(CAST(ratio AS DECIMAL(5,4)), 2)（SQL Server）。
另一个易忽略点是：占比加总未必等于 1.00。由于浮点精度和四舍五入，5 行占比相加可能得 0.99 或 1.01。如需严格满足“组内占比和为 1”，得用“最大余数法”后处理——这已超出窗口函数能力范围，属于应用层校准逻辑。
- 显示用
ROUND()即可，但报表或下游系统若校验总和，得提前沟通容差策略 - 不要在窗口函数内部套
ROUND()再参与后续计算，会放大误差 - 百分比展示（×100）记得同步调整小数位，避免写成
ROUND(ratio * 100, 2) || '%'却忘了ratio本身精度不足
实际写的时候，最常卡住的不是语法，而是没想清楚“组”的边界在哪，以及要不要处理全零组——这两点错了，后面全白搭。
