用窗口函数sum() over()计算占比最稳妥，需确保where条件一致、处理null和除零、兼容数据库版本，并避免在group by后直接套用窗口函数。
直接用窗口函数 SUM() OVER() 算占比最稳
别先 GROUP BY 再连表算总额，容易漏数据或重复聚合。窗口函数能一行内同时拿到当前行销售额和全表总和，天然避开了自连接或子查询的坑。
常见错误是写成 SUM(sales) / SUM(sales) OVER() 却忘了加 WHERE 过滤条件——如果查询本身带了过滤（比如只查某个月），那 OVER() 里没加同样条件，分母就是全表总额，分子却是过滤后金额，结果必然失真。
- 正确写法：
SUM(sales) / SUM(sales) OVER()，且整个查询的WHERE条件必须一致 - 如果要按品类分组再算各品类占全表比例，就用
SUM(sales) OVER(PARTITION BY category)，但分母仍应是SUM(sales) OVER()（不带PARTITION BY） - 注意
NULL值：sales为NULL的行参与SUM()计算时会被忽略，但若整列都是NULL，分母会是NULL，导致结果全为NULL
ROUND() 和除零保护不能省
直接除法结果可能是超长小数，前端展示或导出时容易出格式问题；更关键的是，空表或全 NULL 销售额时，分母为 0 或 NULL，会返回 NULL 或报错（取决于数据库）。
PostgreSQL 和 SQL Server 支持 NULLIF()，MySQL 用 IF() 或 COALESCE() 配合判断，但最通用写法是：
ROUND( COALESCE(sales, 0) * 1.0 / NULLIF(SUM(sales) OVER(), 0), 4 ) AS ratio
-
* 1.0强制转浮点，避免整数除法截断（如 SQLite、旧版 MySQL） -
NULLIF(..., 0)把分母为 0 的情况转成NULL，再由外层COALESCE()统一处理（比如设为 0） -
ROUND(..., 4)控制精度，4 位小数够用，太多反而干扰阅读
不同数据库对 OVER() 的兼容性差异
MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持标准窗口函数；但 MySQL 5.7 及更早版本不支持，得用变量模拟或两层子查询——性能差、逻辑绕，还容易在并发下出错。
- 确认版本：
SELECT VERSION();（MySQL）、SELECT version();（PostgreSQL） - SQLite 3.25+ 支持，但不支持
NULLIF()，得用CASE WHEN ... THEN ... ELSE ... END - 如果必须兼容老 MySQL，优先考虑应用层计算：先查
SUM(sales)，再查明细，用代码除——比硬写 SQL 更可靠
聚合后还要占比？小心逻辑错位
如果已经 GROUP BY product_id 汇总了每款产品的销售额，再想算“每个产品占全表总额比例”，就不能在同一个查询里对聚合结果套 SUM() OVER()——因为此时数据已是聚合态，OVER() 作用范围是当前结果集，不是原始表。
- 正确做法：用子查询或 CTE 先算总额，再和聚合结果 JOIN
- 例如：
WITH total AS (SELECT SUM(sales) AS all_sum FROM orders)，然后SELECT p.product_id, p.sales / t.all_sum FROM (SELECT product_id, SUM(sales) sales FROM orders GROUP BY product_id) p, total t - 别试图在
GROUP BY查询里写SUM(SUM(sales)) OVER()，语法错误，数据库直接拒掉
实际业务里，占比常要叠加时间维度（如“本月销量占今年累计销量比”），这时分母就得变成带时间条件的窗口，而不是简单全表。条件一致性比函数本身更难盯住。
