子查询计算占比结果全为0或NULL，是因为整数除法截断小数且未处理除零；正确做法是用1.0乘分子强制浮点运算，并用NULLIF防除零，或改用窗口函数SUM() OVER()一次性计算总量。
用子查询在SELECT中计算占比时，为什么结果全是0或NULL？
直接写 SUM() 在 SELECT 里会报错或返回空，因为聚合函数不能和非分组字段混用。正确做法是用子查询先算出总量，再在主查询里做除法——但要注意数据类型：整数除整数在多数数据库（如 PostgreSQL、SQL Server）默认截断小数，MySQL 8.0+ 默认也这样。
- 确保分子分母至少一个是浮点类型，比如写成
CAST(count_col AS FLOAT)或直接乘1.0 - 子查询必须返回单个值，否则会报错
subquery must return only one column - 如果总量为 0，除法会出错（如 PostgreSQL 报
division by zero），得加CASE WHEN total = 0 THEN 0 ELSE ... END
MySQL 和 PostgreSQL 中计算占比的写法差异
两者语法接近，但类型处理细节不同。MySQL 对隐式类型转换更宽松，PostgreSQL 更严格；SQLite 则默认整除——这些都会导致比例全为 0。
- MySQL 示例：
count(*) * 1.0 / (SELECT COUNT(*) FROM orders) - PostgreSQL 必须显式转类型：
count(*)::FLOAT / (SELECT SUM(count(*)) OVER())（也可用窗口函数替代子查询） - 避免写
count(*) / (SELECT count(*) FROM t)——整数除整数在 PG/SQL Server 中结果为 0
用窗口函数替代嵌套查询更安全高效
嵌套子查询会在每行重复执行一次总量计算，大数据量时性能差。窗口函数只算一次总量，还能自然规避除零问题。
-
SUM(count_col) OVER()返回整列总和，可直接用于比例计算 - 推荐写法：
count(*) * 1.0 / SUM(count(*)) OVER() - 如果要按类别分组算各自占比，加
PARTITION BY category，比如：count(*) * 1.0 / SUM(count(*)) OVER(PARTITION BY category) - 注意：窗口函数不能用在
WHERE或GROUP BY中，只能出现在SELECT或HAVING
实际业务场景中容易漏掉的边界情况
真实表常有 NULL、过滤条件、多层分组，直接套模板会出错。
- 原始数据含
NULL字段？COUNT(col)会忽略它，但COUNT(*)不会——确认你统计的是“行数”还是“非空值数” - 主查询带
WHERE条件？子查询没同步过滤就会导致分母错误。例如查“已发货订单占比”，子查询也得加WHERE status = 'shipped' - 用
ROUND(x, 4)控制小数位，但别在除法前就ROUND分母——会放大误差
嵌套查询算占比看着简单，真正跑起来卡在类型、NULL、过滤不一致上最常见；窗口函数虽好，但老版本 MySQL 不支持，得先查 VERSION() 确认。
