SUM() OVER()无分组即全表求和，每行值相同，用于计算单笔订单占总额的贡献度；正确写法为amount * 100.0 / SUM(amount) OVER()，需用100.0防整除截断、COALESCE处理NULL、NULLIF或CASE防除零，且兼容MySQL 8.0+及以上版本。
什么是 SUM() OVER() 无分组？
它不是聚合函数的常规用法，而是窗口函数的一种——不带 PARTITION BY 的 SUM() OVER() 会把整张表所有行的值加起来，生成一个“全表总和”列，每行都重复这个值。这正是计算单笔订单占总额百分比的基础。
怎么写贡献度（占比）表达式？
核心是：单笔订单金额 / 全表 SUM(订单金额)。必须用窗口函数算分母，不能用子查询或变量，否则在多行结果中容易出错或性能差。
常见错误现象：SELECT order_id, amount, amount / SUM(amount) FROM orders; 会报错，因为没 GROUP BY；强行加 GROUP BY order_id 又让 SUM(amount) 变成单行自身，失去“总额”意义。
正确写法示例：
SELECT order_id, amount, ROUND(amount * 100.0 / SUM(amount) OVER(), 2) AS contribution_pct FROM orders;
-
SUM(amount) OVER()没有括号内任何参数，就是全表求和 -
amount * 100.0中的100.0强制转为浮点，避免整数除法截断（尤其在 PostgreSQL、SQL Server 中明显） -
ROUND(..., 2)控制小数位，防止出现12.3456789%这类难读结果
为什么不能用子查询替代？
看起来 (SELECT SUM(amount) FROM orders) 也能拿到总额，但实际有隐患：
- 在复杂查询中（比如 JOIN 多表、带 WHERE 条件），子查询可能被重复执行，拖慢性能
- 如果外层有
WHERE过滤，而子查询没同步过滤，就会算错分母（例如只查 2024 年订单，但子查询仍算全表总额） -
SUM() OVER()自动继承当前查询的过滤逻辑，更安全可靠
等价但更稳妥的写法（显式强调作用域）：
SELECT order_id, amount, ROUND(amount * 100.0 / SUM(amount) OVER(ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING), 2) AS contribution_pct FROM orders WHERE order_date >= '2024-01-01';
注意：ROWS BETWEEN ... 是冗余写法，效果和空括号一致，但能提醒自己“这里确实是全局窗口”。
兼容性与边界情况要注意什么？
不同数据库对空 OVER() 支持良好（PostgreSQL、SQL Server、Oracle、Snowflake、DuckDB 都 OK），但 MySQL 8.0+ 才支持，MySQL 5.7 及更早版本不识别，会报错 ERROR 1064。
另外两个易忽略点：
- 如果
amount列含NULL，SUM()会自动忽略它们，但分子如果是NULL，整个占比就变成NULL—— 建议提前用COALESCE(amount, 0) - 当全表
SUM(amount) = 0（比如全为负数或全 NULL），除零会导致结果为NULL或报错（SQL Server 报错，PostgreSQL 返回NaN），需加CASE WHEN SUM(...) = 0 THEN 0 ELSE ... END防御
真正上线前，得检查数据里有没有零总额场景，不然报表上突然冒出一堆 NULL 或报错，排查起来比写法本身还费时间。
