RATIO_TO_REPORT 是 Oracle 等数据库的分析函数，计算当前行值占结果集指定列总和的比例，语法为 RATIO_TO_REPORT(expr) OVER()，不支持 PARTITION BY，分母为 WHERE 过滤后的结果集总和。
什么是 RATIO_TO_REPORT，它算的是什么
RATIO_TO_REPORT 是 Oracle 和某些兼容数据库（如部分版本的 PostgreSQL 通过扩展支持）提供的分析函数，用来计算当前行值占整个结果集某列总和的比例。它不依赖 PARTITION BY，默认对整个查询结果集求和，所以天然适合“全局占比”类需求，比如：各产品销售额占总销售额的百分比。
注意：它不是标准 SQL 函数，MySQL 和 SQLite 原生不支持；SQL Server 用 SUM() OVER() 模拟更常见；PostgreSQL 需要 pg_stat_statements 或自定义窗口函数替代。
它的基本写法是：RATIO_TO_REPORT(expr) OVER()，其中 expr 是数值型表达式，比如销售额字段名。
直接写错的典型报错和原因
常见错误现象包括：
-
ORA-30483: window functions are not allowed here：在WHERE或HAVING子句里直接用了RATIO_TO_REPORT—— 它只能出现在SELECT或ORDER BY中 - 返回全为
NULL：expr列本身含NULL，而RATIO_TO_REPORT对NULL值不参与计算，但若整列都NULL，分母为 0，结果未定义 - 意外出现小数精度问题：比如显示
0.299999999而非0.3，这是浮点运算导致，建议用ROUND(..., 4)控制位数
正确使用前提：确保 expr 可聚合、非空（或已用 NVL/COALESCE 处理），且语句结构是完整查询（不能嵌套在过滤子句中）。
业务场景下怎么加条件再算占比
真正做报表时，往往不是“全表占比”，而是“满足某条件的组内占比”。这时不能只靠 RATIO_TO_REPORT，必须配合 WHERE 先过滤，再开窗：
- 先用
WHERE筛出目标业务范围（例如：时间范围、状态为 'active'、地区为 'CN'） - 再在
SELECT中用RATIO_TO_REPORT(sales_amt) OVER()计算该子集内的占比 - 如果需要“分区域看各自占比”，就得换用
SUM(sales_amt) OVER(PARTITION BY region)手动构造分母，因为RATIO_TO_REPORT不支持PARTITION BY
示例（Oracle）：
SELECT product, sales_amt, ROUND(RATIO_TO_REPORT(sales_amt) OVER(), 4) AS ratio FROM sales WHERE dt >= DATE '2024-01-01' AND status = 'shipped';
这个结果中所有 ratio 加起来一定等于 1（忽略浮点误差）。
和 SUM() OVER() / COUNT() OVER() 的性能与可读性对比
RATIO_TO_REPORT 本质是语法糖，等价于：
sales_amt / SUM(sales_amt) OVER()
两者执行计划几乎一致，Oracle CBO 通常会优化成同一路径。但差异在于：
-
RATIO_TO_REPORT更简洁，意图明确，适合快速写占比逻辑 -
SUM(...) OVER()写法更通用，可跨数据库移植（比如迁到 SQL Server 时只需改写分母） - 若需同时算多个占比（如销售额占比 + 订单量占比），用
SUM写法能复用同一个窗口定义（OVER() AS w），而RATIO_TO_REPORT每个都要重复写OVER() - 在复杂查询中，如果
OVER()里本就带PARTITION BY或ORDER BY，那就根本不能用RATIO_TO_REPORT—— 它不接受这些子句
实际选哪个，取决于你是否锁死 Oracle 生态、是否后续要迁移、以及团队对窗口函数的熟悉程度。
别忘了：RATIO_TO_REPORT 的分母永远是当前结果集的总和，它不会“记住”原始表全量数据——如果你 WHERE 过滤了 90% 数据，那占比就是剩下 10% 样本内部的占比，不是全量口径。这点容易被忽略，尤其在做同比/环比交叉分析时。
