直接在SELECT中写两个子查询相除会导致NULL传播、除零报错（PostgreSQL）、整数截断得0、无法控制精度和格式等问题；应改用派生表配合COALESCE、NULLIF、乘100.0及ROUND统一处理。
直接在 SELECT 中写两个子查询相除会出什么问题
常见错误是把分子、分母都写成独立子查询，比如：(SELECT SUM(money) FROM person) / (SELECT SUM(money) FROM compay)。表面看能跑通，但实际隐患很多：一旦任一子查询返回 NULL（比如某张表为空），整个结果就变成 NULL；如果分母为 0，MySQL 默认不报错但返回 NULL，PostgreSQL 则直接抛 division by zero 错误；更隐蔽的是，这种写法无法加 ROUND 或 CONCAT 控制精度和格式，容易在应用层再处理，增加出错概率。
用派生表（FROM 子查询）统一控制空值与精度
把两个聚合结果先“拎出来”作为临时列，比在 SELECT 里硬套更可控。关键点在于提前用 COALESCE 拦住 NULL，并确保分母不为 0：
-
COALESCE((SELECT SUM(money) FROM person), 0)防止分子为空 -
NULLIF((SELECT SUM(money) FROM compay), 0)把分母为 0 的情况转成NULL，再用外层COALESCE(..., 0)统一兜底 - 乘以
100.0而不是100，避免整数除法截断（尤其在 PostgreSQL/SQL Server 中） - 最后用
ROUND(..., 2)固定小数位，再CONCAT(..., '%')拼百分号
完整写法示例：
SELECT CONCAT(ROUND(COALESCE(p.sum_p, 0) * 100.0 / NULLIF(c.sum_c, 0), 2), '%') AS ratio
FROM (SELECT COALESCE(SUM(money), 0) AS sum_p FROM person) p,
(SELECT COALESCE(SUM(money), 0) AS sum_c FROM compay) c;
GROUP BY 场景下怎么安全算占比
当你要按部门、月份等维度算“本组占全局比例”，别用多层子查询反复扫全表——性能差且难维护。优先用窗口函数：SUM(COUNT(*)) OVER() 是最简方案：
- 聚合后立刻用
OVER()算全局总数，只扫一遍表 - 避免写成
(SELECT COUNT(*) FROM t WHERE dept = t1.dept) / (SELECT COUNT(*) FROM t)这种相关子查询，MySQL 8.0 前几乎没法优化 - 注意类型：
COUNT(*)是整型，除法前必须转成浮点，否则 MySQL 5.7 可能得 0 - 如果需排除某些行（如状态为 'deleted'），窗口函数的
FILTER（PostgreSQL）或条件聚合（MySQL）更清晰，而不是在子查询里重复写 WHERE
例如部门人数占比：
SELECT dept, COUNT(*) AS cnt, ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(), 2) AS pct FROM employees WHERE status != 'deleted' GROUP BY dept;
跨表关联时比例计算的 NULL 陷阱
用 LEFT JOIN 关联两张统计表时，若某一方无匹配数据，对应字段为 NULL，直接相除会得 NULL。不能只靠 IFNULL 补 0——这会把“真实缺失”和“数值为 0”混为一谈：
- 先确认业务语义：分母为 0 是合理场景（如某部门暂无预算），还是数据异常（如漏同步）？前者该显式标
'N/A'，后者应告警 - 用
CASE WHEN c.sum_c IS NULL OR c.sum_c = 0 THEN 'N/A' ELSE CONCAT(ROUND(...), '%') END显式区分 - JOIN 条件要严格，避免因关联字段类型不一致（如
VARCHAR和INT）导致隐式转换失败，让本该匹配的行变NULL - 如果两张表时间范围不一致（如 person 表含 2026 年数据，compay 表只到 2025 年），比例结果毫无意义——务必先对齐时间维度
真正麻烦的从来不是语法，而是搞清“这个 0 是没发生，还是没记录”。算比例之前，先盯住数据源的一致性边界。
