子查询除法结果为0是因整数除法截断，需显式转浮点类型；WHERE条件须同步至子查询或用相关子查询；窗口函数SUM() OVER()更安全高效；百分比需按业务四舍五入或应用层补差，避免浮点精度问题。
子查询里直接除法结果为0？先看数据类型
SQL里用子查询算百分比，最常见问题是 SELECT col / (SELECT SUM(col) FROM t) 返回全0。这是因为整数除整数在多数数据库里自动截断小数——哪怕你用的是PostgreSQL或SQL Server，只要两边都是INT，结果就是整数。
解决方法很简单：把分子或分母显式转成浮点类型。不同数据库写法略有差异：
- MySQL / PostgreSQL：
col::numeric或CAST(col AS DECIMAL) - SQL Server：
CONVERT(DECIMAL(5,2), col) - SQLite：
CAST(col AS REAL)
别依赖隐式转换，尤其当子查询来自视图或CTE时，字段类型可能和表定义不一致。
WHERE条件影响子查询总计？必须确认作用域
如果主查询带了WHERE，而子查询没同步过滤，算出来的百分比就毫无意义。比如你想看“北京用户订单金额占北京总订单的百分比”，但子查询写成 (SELECT SUM(amount) FROM orders)，那算出来其实是占全局总额的比例。
正确做法是让子查询和主查询保持相同过滤逻辑：
- 要么在子查询里重复写一遍
WHERE city = 'Beijing' - 要么用相关子查询（correlated subquery），例如：
(SELECT SUM(o2.amount) FROM orders o2 WHERE o2.city = o1.city)，前提是主查询别名是o1
注意：相关子查询性能较差，数据量大时优先考虑JOIN或窗口函数替代。
用窗口函数替代子查询更安全、更高效
如果你用的是 PostgreSQL 8.4+、SQL Server 2005+、MySQL 8.0+ 或 Oracle，直接用SUM() OVER()比子查询更稳：
SELECT product, amount, ROUND(100.0 * amount / SUM(amount) OVER(), 2) AS pct FROM sales;
好处很明显：
- 不用关心子查询是否被优化器重写
- 天然支持分区，比如按月份分组算占比：
SUM(amount) OVER(PARTITION BY month) - 避免因
NULL值导致整列结果为NULL（子查询返回NULL会让整个除法结果为NULL，而窗口函数默认忽略NULL）
唯一要注意的是OVER()括号不能空着——至少得写OVER()表示全表范围，否则语法报错。
百分比结果要四舍五入还是截断？看业务场景
财务类系统通常要求严格四舍五入到小数点后两位，用ROUND(x, 2)；但有些报表为了凑整100%，需要最后补差额（比如一堆99.99%加起来是99.97%，就得把最大那个调成100.03%）。这种逻辑SQL很难做干净，建议在应用层处理。
另外注意浮点精度问题：
- 不要用
FLOAT存金额再算百分比，容易出现0.29999999999999999这类显示异常 - 用
DECIMAL(10,2)或等效类型，再配合ROUND() - MySQL中
ROUND()对浮点数有“银行家舍入”行为，如需传统四舍五入，可套一层ROUND(x + 0.0000001, 2)
百分比本身不是原子计算，它依赖总计值的稳定性——如果主表和子查询涉及的表存在并发更新，两次执行可能得到不同结果，这点常被忽略。
