窗口函数必须在join之后执行，因它不改变行数而仅添加计算列；需先完成join生成完整宽表，再开窗，否则分区字段缺失或null、重复键会导致逻辑错误。
JOIN 必须在窗口函数之前完成
窗口函数不会改变行数，它只在已有的结果集上添加计算列。所以必须先 JOIN 拼出完整宽表，再开窗——如果在 JOIN 前对单表用 ROW_NUMBER() 或 SUM() OVER，分区字段（比如 user_id）可能还没从另一张表引入，导致 PARTITION BY 失效或分组错乱。
执行顺序固定为：FROM → JOIN → WHERE → WINDOW。常见错误是写成：
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time) FROM orders JOIN users ON orders.user_id = users.id;
看起来没问题，但若 orders 表里本身没有 user_id（比如用了别名或字段名不一致），或 JOIN 后出现重复 user_id 且未去重，窗口函数就会按错误的粒度计算。
LEFT JOIN 遇到 NULL 时的分区陷阱
PARTITION BY 字段值为 NULL 时，所有 NULL 会被归入同一组。例如用 LEFT JOIN 关联用户和订单后，对 user_id 开窗，那些没订单的用户会全部挤进一个“NULL 分区”，导致 ROW_NUMBER() 或累计求和逻辑崩坏。
- 检查
JOIN后user_id是否有意外NULL：加WHERE user_id IS NOT NULL或提前用COALESCE(user_id, -1)隔离 - 若业务允许，优先用
INNER JOIN避免该问题；否则在开窗前用CASE WHEN对NULL做兜底处理 - 排序字段也别依赖
NULL值，比如ORDER BY order_time DESC中若order_time可为空，建议补NULLS LAST（PostgreSQL/Oracle）或用COALESCE(order_time, '1970-01-01')
重复键引发的笛卡尔积会让窗口结果虚高
当右表存在“一主多从”关系（如一个用户对应多条地址记录、多个状态快照），又没做预处理就直接 JOIN，会产生冗余行——窗口函数会在这些重复行上照样计算，导致 SUM() OVER 结果翻倍、ROW_NUMBER() 排序错乱。
正确做法是在 JOIN 前用窗口函数收拢右表：
SELECT u.name, o.order_id, o.amount
FROM users u
LEFT JOIN (
SELECT user_id, order_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) o ON u.id = o.user_id AND o.rn = 1;
注意：o.rn = 1 必须写在 ON 条件里（不是 WHERE），否则 LEFT JOIN 会退化成 INNER JOIN。
容易忽略的点：
-
ROW_NUMBER()的ORDER BY必须带确定性，秒级时间戳相同就加order_id兜底 - 没索引时
PARTITION BY user_id ORDER BY created_at可能触发磁盘排序，建议在(user_id, created_at)上建联合索引 - 别在
ON里直接写窗口函数表达式，语法不支持，必须用子查询或 CTE 包裹
WHERE 过滤要放在窗口之前
窗口函数不减少行数，它只是给每行加新列。如果把 WHERE 放在开窗之后，等于先对全量数据开窗再过滤，白白浪费计算资源。
比如查“每个客户最近 3 个月的累计消费”，应该：
- 先
JOIN+WHERE order_time >= '2026-04-01'把无关月份剔除 - 再在过滤后的结果上用
SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time ROWS UNBOUNDED PRECEDING)
而不是反过来：先开窗算出所有历史累计值，再用 WHERE 筛时间——后者性能差，且累计值包含被过滤掉的旧数据，逻辑错误。
复杂逻辑建议拆成 CTE，语义清晰也方便调试：
WITH base AS (
SELECT u.id, u.name, o.amount, o.order_time
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.order_time >= '2026-04-01'
)
SELECT *,
SUM(amount) OVER (PARTITION BY id ORDER BY order_time) AS cum_amount
FROM base;
实际写的时候，最容易被跳过的不是语法，而是 JOIN 后行数是否合理、NULL 怎么分布、重复键有没有被收拢——这些不肉眼检查，窗口函数就算写对了，结果也是错的。
