为何CMU数据库课程题官方方案偏好不同聚合方式计算延迟订单占比？

问题背景 #

我正在完成CMU公开数据库系统课程的习题，现有Order表与Shipper表，需求为计算每个承运商的延迟订单占比（延迟定义为ShippedDate > RequiredDate）。我编写的简洁查询语句能得到正确结果，但官方采用了更复杂的子查询聚合方案，二者输出结果一致，现咨询官方方案相较于我所用方法的优势。

我的实现代码 #

SELECT 
    CompanyName, 
    ROUND(100*SUM(IIF(ShippedDate > RequiredDate, 1, 0))/Cast(Count(ShipName) as Float), 2) as percent 
FROM 'Order' AS O 
JOIN Shipper AS S 
ON O.ShipVia = S.Id 
GROUP BY CompanyName 
ORDER BY percent DESC;

官方实现代码 #

SELECT CompanyName, round(delayCnt * 100.0 / cnt, 2) AS pct
FROM (
      SELECT ShipVia, COUNT(*) AS cnt 
      FROM 'Order'
      GROUP BY ShipVia
     ) AS totalCnt
INNER JOIN (
            SELECT ShipVia, COUNT(*) AS delaycnt 
            FROM 'Order'
            WHERE ShippedDate > RequiredDate 
            GROUP BY ShipVia
           ) AS delayCnt
          ON totalCnt.ShipVia = delayCnt.ShipVia
INNER JOIN Shipper on totalCnt.ShipVia = Shipper.Id
ORDER BY pct DESC;

官方方案的优势 #

• 逻辑拆分更清晰：把「统计每个承运商总订单数」和「统计每个承运商延迟订单数」拆成两个独立子查询，每个子查询只承担单一统计职责，阅读代码时能快速理解各部分功能，更适合团队协作或后续维护。
• 性能优化空间更大：
  • 若Order表存在ShipVia字段的索引，两个子查询都能高效利用索引完成分组统计，避免了主查询中同时进行条件判断与聚合的混合操作。
  • 针对延迟订单占比极低的场景，第二个子查询仅筛选延迟订单后再分组，处理的数据量远小于全表扫描加条件判断的方式。
• 数据库兼容性更强：IIF函数是部分数据库（如SQL Server）的专属语法，子查询方案几乎兼容所有主流关系型数据库（MySQL、PostgreSQL、Oracle等），无需因数据库类型调整核心逻辑。
• 功能扩展性更好：后续若需新增统计维度（如按时订单数、分时段延迟占比），只需在现有子查询基础上新增统计分支即可，无需修改原有聚合逻辑，代码改动更可控。

内容的提问来源于stack exchange，提问作者Andrew Parmar