<p>最直接的方法是用COUNT() OVER()作分母：SELECT status, COUNT() AS cnt, ROUND(COUNT() 100.0 / COUNT() OVER(), 2) AS pct FROM orders GROUP BY status；需用100.0防整除截断，COUNT() OVER()获取全表总行数，NULL分组字段会被单独成组但不计入COUNT(*)。</p>
用 COUNT(*) OVER() 当分母最直接
想算每个 status 值占全表行数的百分比，核心是让每组都能“看到”总行数。COUNT(*) OVER() 就是干这个的：它不参与 GROUP BY 分组逻辑，对每一行都返回整张表的总行数。
常见错误是写成 COUNT(*) / (SELECT COUNT(*) FROM t) —— 子查询多扫一次表，嵌套深了还容易漏别名或条件；更糟的是有人把 COUNT(*) OVER() 和 COUNT(*) 直接放同一层除，比如 COUNT(*) / COUNT(*) OVER()，这在多数数据库里会报错，因为聚合和窗口不能裸混用。
- 必须用
* 100.0或CAST(... AS DECIMAL)强制浮点运算，否则整数除法（如5 / 10）结果为0 -
COUNT(*) OVER()自动包含所有行，包括status为NULL的行；如果业务上要排除NULL，得提前WHERE status IS NOT NULL - 示例语句：
SELECT status, COUNT(*) AS cnt, ROUND(COUNT(*) * 100.0 / COUNT(*) OVER(), 2) AS pct FROM orders GROUP BY status;
AVG(CASE WHEN ... THEN 1.0 ELSE 0 END) 更简洁，但要注意 NULL
统计 “某状态是否出现” 的占比（比如 status = 'paid' 的比例），AVG() 比 SUM()/COUNT() 少写一半代码，且天然规避除零风险（空组返回 NULL，不是报错）。
但它对 NULL 敏感：如果 status 字段本身有 NULL 值，AVG(CASE WHEN status = 'paid' THEN 1.0 ELSE 0 END) 会把 NULL 行当 0 算入分母；而 SUM(CASE ...) / COUNT(*) 的分母也含这些 NULL 行，两者结果一致。但如果写成 AVG(CASE WHEN status = 'paid' THEN 1.0 ELSE NULL END)，NULL 就被 AVG 忽略，分母变小，结果偏高。
- 推荐统一用
ELSE 0，和COUNT(*)分母对齐 - SQLite 不支持布尔转数值，必须用
SUM/COUNT替代 - 示例：
SELECT AVG(CASE WHEN status = 'paid' THEN 1.0 ELSE 0 END) AS paid_rate FROM orders;
按多字段分组时，PARTITION BY 决定分母范围
如果要算 “每个 region 内各 status 的占比”，分母就不能是全表总数，而是每个 region 内的行数。这时必须用带 PARTITION BY 的窗口函数，比如 COUNT(*) OVER(PARTITION BY region)。
常见错误是只改 GROUP BY region, status，但分母仍用 COUNT(*) OVER()，结果变成 “该 region+status 组占全表比例”，而不是 “占本 region 比例”。
- 分母写法必须和业务口径严格匹配：
PARTITION BY region对应 “按大区看”，PARTITION BY region, product_type对应 “按大区和品类组合看” - MySQL 5.7 或旧版 PostgreSQL 不支持窗口函数，只能用自连接或相关子查询，务必核对子查询
WHERE条件字段和外层GROUP BY完全一致，否则分母错位 - 示例：
SELECT region, status, COUNT(*) * 100.0 / COUNT(*) OVER(PARTITION BY region) AS pct_in_region FROM orders GROUP BY region, status;
过滤条件写在 WHERE 还是聚合里，直接影响分母含义
如果需求是 “已支付订单占所有非取消订单的比例”，分母是 “status != 'cancelled'” 的行数，不是全表。这时候不能先 WHERE status != 'cancelled' 再算，否则分子（status = 'paid'）也被限制在同一子集里，结果永远 ≤ 100%，但语义就变成了 “在非取消单里，已支付单占多少”——这没错，但如果你本意是 “已支付单占全部订单的比重”，那分母就必须拉回全表，用 COUNT(*) OVER()。
更安全的做法是把条件逻辑收进聚合：分子用 SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END)，分母用 COUNT(*) FILTER (WHERE status != 'cancelled')（PostgreSQL）或等价的 SUM(CASE WHEN status != 'cancelled' THEN 1 ELSE 0 END) OVER()（通用）。
- 业务字段命名要体现分母基准，比如
paid_of_non_cancelled比paid_rate更不易误解 -
WHERE是全局筛选，影响所有聚合结果；CASE WHEN是行级逻辑，只影响当前聚合项 - 没加
WHERE时，NULL状态会被单独分组，但不会出现在CASE WHEN status = ...的分子里，这点要和产品对齐是否合理
真正容易被忽略的，是分母的“参照系”到底由谁定义：它可能来自全表、某个分组、某个过滤子集，甚至跨时间周期。写之前先问一句：这个百分比，是相对于哪一堆数据算出来的？答案决定了你该用 OVER()、OVER(PARTITION BY ...)，还是显式子查询。
