RATIO_TO_REPORT是计算某值占窗口内非NULL值总和比例的分析函数，本质为value/SUM(value) OVER(...)的语法糖；与SUM() OVER不同，它不支持ORDER BY、不能嵌套分析函数，且分母自动排除NULL，而SUM() OVER可灵活控制聚合逻辑并支持更多窗口修饰。
什么是 RATIO_TO_REPORT，它和 SUM() OVER 的区别在哪
RATIO_TO_REPORT 是 Oracle 和一些兼容数据库（如 StarRocks、Doris）提供的分析函数，用于直接计算某列值占其窗口内总和的比例。它本质是 value / SUM(value) OVER (...) 的语法糖，但关键差异在于：它**不支持 PARTITION BY 子句里的复杂表达式或多列组合**（Oracle 12c+ 有限支持），且**无法单独控制分母的聚合逻辑**——分母永远是当前窗口下该列所有非 NULL 值的 SUM。
常见误用是把它当 PERCENT_RANK 或 CUME_DIST 用，但它只做“除法”，不做排序或累积。
基础写法与 NULL 值处理要特别注意
最简形式：RATIO_TO_REPORT(col) OVER()，分母为整列非 NULL 值之和；加 PARTITION BY 后，分母变为各组内非 NULL 值之和。
- 如果
col有 NULL，它们不参与分子计算（分子为 NULL），也不计入分母（分母不含 NULL）——这是隐式行为，容易导致比例总和 ≠ 1.0 - 想把 NULL 当 0 处理？必须显式写成
RATIO_TO_REPORT(COALESCE(col, 0)) OVER(...) - 分母为 0 时（整组全 NULL 或全 0），结果返回 NULL，不会报错
示例：
SELECT dept, salary,
ROUND(RATIO_TO_REPORT(salary) OVER(PARTITION BY dept), 3) AS ratio
FROM emp;
在 MySQL 或 PostgreSQL 中没有 RATIO_TO_REPORT 怎么办
MySQL 8.0+、PostgreSQL 8.4+ 等主流开源数据库原生不支持该函数，必须手写等价逻辑：
- 用
salary / SUM(salary) OVER(PARTITION BY dept)替代，但要注意除零——加NULLIF更安全：salary / NULLIF(SUM(salary) OVER(PARTITION BY dept), 0) - 若需保留两位小数且避免浮点误差，建议外层套
ROUND(..., 4)，别依赖数据库默认精度 - PostgreSQL 中
SUM()窗口函数对 NULL 的处理和 Oracle 一致，无需额外适配
性能和可读性取舍：什么时候该用，什么时候该避开
在 Oracle 中，RATIO_TO_REPORT 和等价的 SUM() OVER 写法执行计划几乎一致，优化器会自动归一化。真正影响性能的是窗口定义本身——尤其是 OVER(ORDER BY ...) 会强制排序，而 RATIO_TO_REPORT **不接受 ORDER BY**，所以它天然比带排序的窗口函数快一点。
- 如果只要组内占比，且不关心行序，优先用
RATIO_TO_REPORT，语义更清晰 - 如果后续还要基于同一窗口做累计、排名等操作，统一用
SUM() OVER避免重复计算窗口 - 跨数据库迁移时，硬编码
RATIO_TO_REPORT会导致 SQL 报错，建议封装成视图或应用层计算
实际跑批时见过因忘记 COALESCE 导致某组比例总和只有 0.87 的 case，查了半小时才发现是 NULL 消掉了分母——这种细节不在执行计划里体现，只能靠数据校验。
