子查询嵌套在SELECT列表中算占比必须用标量子查询，即子查询只返回单个值，否则会报错；多维度占比应优先用窗口函数，避免N次全表扫描；过滤逻辑需统一收口至CTE以确保分母准确。
子查询嵌套在 SELECT 列表里算占比，必须用聚合函数对齐层级
直接在 SELECT 中写子查询算占比（比如某类销量占总销量比），最常见错误是子查询没加 GROUP BY 或漏了外层分组字段，导致返回多行报错 Subquery returns more than 1 row。正确做法是：子查询本身不能带 GROUP BY（除非用相关子查询），而要靠外层分组和聚合函数对齐维度。
例如统计每个 category 的销售额占全表比例：
SELECT category, SUM(amount) AS cat_total, SUM(amount) / (SELECT SUM(amount) FROM orders) AS ratio FROM orders GROUP BY category;
注意：(SELECT SUM(amount) FROM orders) 是标量子查询，只返回一个值，才能参与除法；如果误写成 (SELECT SUM(amount) FROM orders GROUP BY category)，就会报错。
多维度交叉占比（如城市×品类）需用窗口函数替代多层子查询
当需要按两个及以上字段分组后，再算“该组合占其所在城市总和的比”或“占该品类总和的比”，硬套子查询极易出错或性能爆炸。这时候子查询不是不能用，而是不划算——每行都要执行一次独立子查询，N 行就是 N 次全表扫描。
更合理的方式是用窗口函数，它天然支持多级分区：
- 占所在
city的比：SUM(amount) / SUM(SUM(amount)) OVER (PARTITION BY city) - 占所在
category的比：SUM(amount) / SUM(SUM(amount)) OVER (PARTITION BY category) - 同时看两个维度占比（无需子查询）：
SUM(amount) / SUM(SUM(amount)) OVER ()是全局比，配合PARTITION BY city, category可做更细粒度归一化
若数据库不支持窗口函数（如 MySQL 5.7），才退而求其次用相关子查询，但必须确保子查询中 WHERE 条件能唯一绑定外层当前行的维度值，例如：
SELECT
city, category,
SUM(amount) AS local_sum,
SUM(amount) / (
SELECT SUM(amount) FROM orders o2
WHERE o2.city = o1.city
) AS city_ratio
FROM orders o1
GROUP BY city, category;WHERE 条件中用子查询过滤时，占比基数容易被意外缩小
很多人想“先筛出高价值客户，再算他们内部的品类占比”，于是写：
SELECT category, COUNT(*) / (SELECT COUNT(*) FROM users WHERE score > 80) FROM users WHERE score > 80 GROUP BY category;
看起来没问题，但一旦 WHERE 条件和子查询条件不完全一致（比如子查询漏了 status = 'active'），占比分母就错了。更隐蔽的问题是：如果外层 GROUP BY 字段在部分数据中为 NULL，而子查询没处理，会导致除零或 NULL 结果无法识别。
建议把过滤逻辑统一收口到 CTE 或派生表里：
WITH filtered AS ( SELECT * FROM users WHERE score > 80 AND status = 'active' ) SELECT category, COUNT(*) * 1.0 / (SELECT COUNT(*) FROM filtered) AS ratio FROM filtered GROUP BY category;
MySQL 8.0+ 和 PostgreSQL 中，CTE + 子查询比嵌套子查询更易读且可复用
当占比计算涉及多个中间步骤（比如先算各渠道转化率，再算转化率的分布占比），嵌套子查询会迅速变成“括号迷宫”。此时用 CTE 不仅避免重复写相同子查询，还能让每一步命名清晰：
WITH channel_conv AS ( SELECT channel, COUNT(DISTINCT user_id) AS conv_users FROM events WHERE event = 'purchase' GROUP BY channel ), total_conv AS ( SELECT SUM(conv_users) AS total FROM channel_conv ) SELECT c.channel, c.conv_users, c.conv_users * 1.0 / t.total AS share_of_total FROM channel_conv c CROSS JOIN total_conv t;
注意：CROSS JOIN 在这里安全，因为 total_conv 只有一行；如果不确定，用 (SELECT total FROM total_conv) 更稳妥。另外，除法中显式乘 * 1.0 是为了防止整数除法截断（尤其在 PostgreSQL 和旧版 MySQL 中）。
真正难的不是写出某个占比，而是厘清“分母到底该包含哪些行、是否受外层 WHERE 或 JOIN 影响”。每次写子查询前，先手写一句自然语言：“这个分母应该统计哪几张表、满足什么条件的所有记录”，再翻译成 SQL——漏掉这一句，后面全是调试。
