窗口函数支持“聚合+明细”一次计算，如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 或 HAVING 里反复引用子查询结果清晰得多。
替代关联子查询时避免重复逻辑
比如查“每个用户最新一笔订单的金额”，用关联子查询要写：
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;
关键点：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC) 把“找最新”这个意图封装成一个可命名、可复用的计算列，而不是散落在 WHERE 和子查询里的隐含逻辑。
PARTITION BY + ORDER BY 顺序必须和索引一致
可读性再好，执行慢也白搭。如果常写 AVG(score) OVER (PARTITION BY class_id ORDER BY submit_time)，但没建索引，数据库就得对每个班的数据全排序——千万行表可能卡住。
- 必须建联合索引：
(class_id, submit_time)，顺序不能反 -
ORDER BY漏写会导致ROW_NUMBER()结果不稳定，PostgreSQL 直接报错，MySQL 可能每次执行序号都不同 - 窗口函数输出不能直接进
WHERE，想筛“累计值 > 100”的行，得套一层子查询，这点容易忘
