你正在编写一份经营分析报表，需要按门店统计已经完成支付的订单所占的比例。直觉上可能会先按门店分组，用两个COUNT分别统计总订单和已付订单，然后在HAVING或外层做除法。这种方式并没有错，但SQL其实提供了一种更紧凑、更巧妙的写法——在AVG聚合函数内部结合CASE WHEN表达式，直接把条件判断和比例计算合二为一。本文将围绕这一技巧展开，从原理到实战逐步深入，帮你写出更简洁、更高效的条件百分比统计SQL。
为什么需要统计分组内的条件百分比
在数据分析与报表系统中，单纯统计各分组的记录数往往无法满足业务需求，决策者更关心的是“占比”。例如：每个商品的好评率（好评数/总评价数）、每个销售区域的客户转化率、每年度不同支付渠道的使用比例等。这些问题的共同点是：首先需要对数据按照某个维度（如商品、区域、年份）进行分组，然后在每个组内计算符合特定条件的记录数相对于总记录数的百分比。
如果用常规思路，许多人会选择先计算出分子和分母，再做除法。比如，先用子查询或CTE按组统计总数，再关联一个按组统计条件计数的结果。这样虽然能完成任务，但查询层次增多，代码重复，且多次扫描同一张表，在数据量较大时性能堪忧。而利用AVG函数的数值特性，我们可以直接在一条SELECT语句的分组查询中完成全部计算，大幅简化SQL结构。
AVG与CASE WHEN是如何配合的
要理解这个技巧，首先需要回顾CASE WHEN的本质。CASE WHEN condition THEN 1 ELSE 0 END这样的表达式会对每一行进行求值：如果condition为真，返回1；否则返回0。因此，它实际上将每一行的逻辑条件转换成了一个数值——1表示满足，0表示不满足。当使用聚合函数AVG对这个数值列进行处理时，AVG会计算所有行的平均值，而平均值恰好就是“1”所占的比例。假设某组内有N条记录，其中有M条满足条件，那么AVG得到的就是(M * 1 + (N - M) * 0) / N = M / N，恰好等于我们想要的条件百分比。
这种转换非常直观，而且避免了显示的除法操作和多次聚合。在很多数据库系统中，AVG是基于SUM和COUNT在内部优化的，因此性能表现良好。值得一提的是，该技巧不仅适用于简单的真/假判断，还可以通过嵌套CASE WHEN处理多级条件，返回小数权重的场景同样适用。
基础实战：计算每个产品的订单支付率
假设我们有一张订单表orders，包含字段order_id（订单ID）、product（产品名称）、status（状态，取值'paid'或'unpaid'）。现在要统计每种产品的支付率，即status='paid'的订单占比。使用AVG(CASE WHEN)的SQL可以写成：
SELECT
product,
AVG(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS payment_rate,
COUNT(*) AS total_orders
FROM orders
GROUP BY product;
查询结果中，payment_rate字段就是0到1之间的小数，代表支付比例。如果想以百分比形式展示，可以乘以100并进行格式化，但核心逻辑已经一目了然。相比于分别统计的写法，这段SQL只用了一次表扫描和一次分组聚合，逻辑清晰，维护起来也更轻松。对于没有支付记录的组（比如某个产品从未有过paid状态），AVG会返回0，而非NULL，这一点也符合直觉，因为0%是正确的占比。
如果需要同时统计多个条件占比，比如支付率、退款率（假设状态还有'refunded'），可以在同一个SELECT中并列添加多个AVG(CASE WHEN)，每个对应一种状态，无需额外子查询：
SELECT
product,
AVG(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_rate,
AVG(CASE WHEN status = 'refunded' THEN 1 ELSE 0 END) AS refund_rate,
COUNT(*) AS total
FROM orders
GROUP BY product;
这样一次查询就能得到多维度的占比数据，非常适合填充报表的百分比列。
复杂条件下的灵活扩展
实际业务中的条件往往不止一个字段的简单比较。比如统计「最近30天内」各品类的高价值订单占比，条件可能是order_amount > 500且order_date在30天窗口内。利用同样的模式，只需在CASE WHEN中组合多个判定即可：
SELECT
category,
AVG(CASE WHEN order_amount > 500 AND order_date >= CURRENT_DATE - INTERVAL '30' DAY
THEN 1 ELSE 0 END) AS high_value_ratio
FROM orders
GROUP BY category;
当条件变得更加分层，例如需要根据不同的区间给予不同权重时，CASE WHEN也可以返回0-1之间的连续值。比如计算客户满意度加权得分，可以用CASE WHEN rating = 5 THEN 1.0 WHEN rating = 4 THEN 0.8 ... END，然后用AVG得到加权后的均值。这种思路还能扩展到更复杂的评分卡模型中。
另一个常见场景是跨行条件统计，比如统计每个部门里收入排名前20%的员工占比。此时可以先通过窗口函数给每位员工按收入排名，然后在外层查询中用AVG(CASE WHEN percentile <= 0.2 THEN 1 ELSE 0 END)进行分组统计。这让SQL的表达能力从单纯的聚合统计延伸到了顺序相关的分布计算。
性能对比与替代方案分析
与子查询方案相比，AVG(CASE WHEN)的最大优势是减少表扫描次数。典型的子查询写法可能是：
SELECT
product,
(SELECT COUNT(*) FROM orders o2 WHERE o2.product = o.product AND status = 'paid')
* 1.0 / COUNT(*) AS rate
FROM orders o
GROUP BY product;
这种相关联子查询会导致每一组都执行一次额外的查询，数据量一大就会严重拖慢性能。而AVG(CASE WHEN)把所有逻辑融合在主聚合查询中，仅需一次全表扫描或一次索引扫描即可完成。在PostgreSQL、MySQL 8.0+等现代数据库上，执行计划通常会显示为单次全表聚合，效率明显更高。
另一种替代方案是使用窗口函数SUM/COUNT OVER配合聚合子查询，例如先用窗口函数计算出总数和条件数，再在外层做除法。这种方式虽然也能避免重复扫描，但查询层次往往更复杂，可读性不如AVG(CASE WHEN)。当然，如果业务需求本身就是需要每一行的明细值附带分组百分比，窗口函数也许更合适；而单纯的分组聚合百分比，AVG(CASE WHEN)是性价比最高的选择。
注意事项与容错处理
使用该技巧时需要留意NULL值的影响。如果CASE WHEN中引用的列可能为NULL，而你的条件没有覆盖NULL的情况，那么该行的CASE结果可能是NULL。AVG函数会忽略NULL值，这有时会导致分母变小，从而计算出不准确的百分比。例如，当status可能为NULL时，应当明确写出ELSE 0或者使用COALESCE确保返回0或1。
另一个常见问题是：如果某个分组完全没有数据，GROUP BY不会产生该组的结果行。这通常符合业务预期，但如果需要展示占比为0的组，可以用左连接或使用COALESCE在外层处理。当分组内记录数不为零但所有条件均为假时，AVG返回0，结果是安全的。至于精度，AVG默认返回数值类型，可以手动转换成DECIMAL或乘以100保留小数位数，以满足展示要求。
最后，不同数据库对CASE WHEN的优化略有差异，但整体上都支持这种写法。只要确保条件中的字段有合适的索引，查询效率就能得到保障。在生产环境中，建议用EXPLAIN查看执行计划，确认是否出现了不必要的全表扫描，并据此对比调整索引策略。