为什么在SQL中使用WINDOW子句能提高代码可读性？

窗口函数的作用，说白了就是让 SQL 能同时拿到“聚合值”和“明细行”——一边保留每一行记录，一边还能算出分组的总和、平均值之类的统计量。比如 SUM() OVER(PARTITION BY)，一行表达式就把“每行订单金额”和“所属用户的总消费额”一起带出来，省去了过去那种套子查询、反复嵌套的笨办法。当然，写的时候别忘了配合列别名，不然代码读起来跟天书似的。还有一个容易踩坑的地方：PARTITION BY 和 ORDER BY 的字段顺序，必须跟表的联合索引顺序一致，否则性能说崩就崩。

下面拆开细说，看看窗口函数到底好在哪里。

窗口函数让“聚合+明细”一次写清

传统 GROUP BY 一聚合就丢行——你想查每个订单明细，同时又想显示每个用户的总消费额，要么套子查询，要么 JOIN 加 GROUP BY，逻辑绕上三层，代码就面目全非了。用 SUM(amount) OVER (PARTITION BY user_id)，一行搞定。每一行订单都带着它所属用户的总额，不用再跳转到子查询里去猜定义，直观得很。

别名配合窗口列让语义一目了然

光写 SUM(sales) OVER (PARTITION BY region ORDER BY month)，别人看了可能还要反应一会儿。加个列别名就清楚多了：

SELECT  
  region,  
  month,  
  sales,  
  SUM(sales) OVER (PARTITION BY region ORDER BY month) AS cum_sales_by_region  
FROM sales_data;

这里 cum_sales_by_region 直白地告诉你“按区域滚动累加”，比在 WHERE 或 HA VING 里翻来覆去引用子查询结果，清爽太多了。

替代关联子查询时避免重复逻辑

举个常见的例子：查每个用户最新一笔订单的金额。用关联子查询这么写：

SELECT o1.user_id, o1.amount  
FROM orders o1  
WHERE o1.order_time = (  
  SELECT MAX(o2.order_time)  
  FROM orders o2  
  WHERE o2.user_id = o1.user_id  
);

但窗口函数只需要把“找最新”这个意图封装成一个计算列：

SELECT user_id, amount  
FROM (  
  SELECT user_id, amount,  
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) AS rn  
  FROM orders  
) t  
WHERE rn = 1;

关键区别：窗口函数让逻辑变成“可命名、可复用”的字段，而不是散落在 WHERE 和子查询里的隐含条件。以后维护起来，一眼就能看出你在干什么。

PARTITION BY + ORDER BY 顺序必须和索引一致

可读性再好，执行慢也白搭。如果常写 A VG(score) OVER (PARTITION BY class_id ORDER BY submit_time)，但没建合适的索引，数据库就得对每个班级的数据全排序——千万行表可能直接卡住。

• 必须建联合索引：(class_id, submit_time)，顺序不能反
• ORDER BY 漏写会导致 ROW_NUMBER() 结果不稳定——PostgreSQL 直接报错，MySQL 可能每次执行序号都不同
• 窗口函数的输出结果不能直接放进 WHERE 里筛选。想筛“累计值 > 100”的行，还得再套一层子查询。这点容易忘，得多留个心眼