sum over 不能直接除以组内总数，因为分母需为同组聚合结果而非全表总和；正确写法是分子用当前行值、分母用同partition by的sum窗口函数，并用coalesce处理null、nullif防零除。
为什么 SUM OVER 不能直接除以组内总数？
直接写 SUM(column) OVER (PARTITION BY group_col) / SUM(column) OVER () 会算错——后者是全表总和，不是当前组的总和。分摊百分比必须基于「本组内部」的占比，所以分母得是同组的聚合结果，但 SUM() OVER 的窗口函数本身不支持在同一个窗口定义里嵌套另一个带 PARTITION BY 的聚合来当分母。
正确写法：用两个独立的窗口函数对齐计算
核心思路是把分子和分母都做成同粒度的窗口表达式，让它们按相同 PARTITION BY 对齐：
- 分子：当前行值（或需要分摊的字段），比如
amount - 分母：该组内所有行的
SUM(amount) OVER (PARTITION BY category) - 结果：用浮点除法避免整数截断，例如乘以
1.0或显式转DECIMAL
示例：
SELECT
category,
product,
amount,
ROUND(
amount * 100.0 / SUM(amount) OVER (PARTITION BY category),
2
) AS pct_in_group
FROM sales;
注意 ROUND(..., 2) 是为了可读性，不是必须；若需更高精度，改小数位即可。
常见错误：NULL 值导致整组百分比为 NULL
只要 amount 中任意一行是 NULL，SUM(amount) OVER (...) 就返回 NULL，进而让整个除法结果为 NULL。这不是 bug，是 SQL 标准行为。
- 修复方法：用
COALESCE(amount, 0)替换amount，确保分子不为 NULL - 更稳妥：分母也加保护，如
SUM(COALESCE(amount, 0)) OVER (PARTITION BY category) - 如果业务上 NULL 表示“未发生”，那补 0 合理；如果表示“未知”，补 0 可能歪曲分摊逻辑，得先确认语义
性能与兼容性要注意什么？
SUM() OVER 在主流数据库（PostgreSQL、SQL Server、Oracle、Snowflake、BigQuery）都支持，但 MySQL 8.0+ 才稳定支持窗口函数。
- 执行计划里，这类计算通常触发一次全扫描 + 排序（按
PARTITION BY字段），数据量大时注意索引是否覆盖PARTITION BY列 - 避免在
WHERE过滤前就计算窗口——否则无效行仍参与分母统计。应先过滤再开窗，或用 CTE 显式隔离 - 某些旧版 Hive/Trino 默认不开启窗口函数优化，可能报
OVER clause is not supported，需检查引擎配置
分摊类计算最易被忽略的是 NULL 传播和分母为零——哪怕业务上不会出现零和，也建议加 NULLIF(..., 0) 防止运行时报错。
