子查询中分母必须为全局统计值，不可随外层GROUP BY分组；正确写法是用不带GROUP BY的标量子查询（如(SELECT COUNT(*) FROM orders)），并注意关联、类型转换及除零处理。
子查询里怎么写分母才能正确算占比
分母必须是全局统计值，不能跟着外层 GROUP BY 一起分组——否则就变成 100% 了。常见错误是把总数也套进同一层 GROUP BY，结果每个组的分子分母都一样。
- 正确做法：用不带
GROUP BY的子查询单独算总数，比如(SELECT COUNT(*) FROM orders) - 如果要按某维度算占比（比如各城市订单占总订单比），分母仍是全表总数；若要算“各城市订单占该地区订单比”，分母就得是地区级聚合，这时得用窗口函数或关联聚合表，不是单层子查询能解决的
- 注意 NULL 处理：如果分子可能为 NULL（如
COUNT(CASE WHEN status='done' THEN 1 END)），除法前建议加COALESCE(..., 0)避免结果为 NULL
MySQL 和 PostgreSQL 在子查询占比里的语法差异
主要差在是否允许子查询直接出现在 SELECT 列表里——MySQL 8.0+ 和 PostgreSQL 都支持，但老版本 MySQL（5.7）会报错 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'，其实和占比无关，但常因误加 LIMIT 触发。
- 安全写法：所有主流版本都支持标量子查询，即返回单值的子查询，例如
(SELECT COUNT(*) FROM users WHERE active=1) - PostgreSQL 支持更灵活的写法，比如在
FROM子句中用(SELECT ...)当作临时表，但 MySQL 要求显式别名，否则报错Every derived table must have its own alias - 别用
AVG()代替占比计算：比如AVG(status='done')看似简洁，但语义是“逻辑真值均值”，在 NULL 存在时行为不一致，不如显式写COUNT(CASE ...)/COUNT(*)
为什么 GROUP BY 后嵌套子查询容易出错
因为子查询执行时机——它在每组数据上独立执行一次，而不是先算完再分组。如果子查询没加过滤条件，就会反复算全表，性能爆炸；如果加了条件但没关联外层，结果就全是静态值。
- 典型陷阱：
SELECT city, (SELECT COUNT(*) FROM orders WHERE city = 'Beijing') / COUNT(*) FROM orders GROUP BY city—— 这里子查询里的'Beijing'是字面量，不是当前组的city，结果每行分母都是北京订单数 - 正确关联写法：MySQL/PostgreSQL 都支持相关子查询，用外层字段引用，如
(SELECT COUNT(*) FROM orders o2 WHERE o2.city = o1.city)，但必须给外层表起别名（o1）才能被子查询引用 - 性能警告：相关子查询是 N×M 复杂度，10 万行分 100 组，就要执行 100 万次扫描。真要算组内占比，优先考虑窗口函数
SUM() OVER (PARTITION BY city)
实际跑不通时先查这三件事
90% 的占比子查询报错或结果异常，都卡在这三个地方。
- 检查子查询是否真的只返回一行一列：用
SELECT (SELECT COUNT(*) FROM xxx) AS cnt单独执行，看有没有多行或多列报错 - 确认除法两边类型：有些数据库（如 PostgreSQL）整数除整数得整数，
5/10结果是0，得写成5.0/10或CAST(5 AS FLOAT)/10 - 验证分母是否可能为零：
WHERE条件太严导致分母为 0，整个表达式会返回NULL或报错（取决于数据库配置），加CASE WHEN denominator = 0 THEN 0 ELSE numerator/denominator END更稳妥
