窗口函数必须在JOIN之后执行，因其依赖JOIN生成的完整宽表，若先开窗则PARTITION BY字段可能不存在、为NULL或重复，导致结果不可信；需确保JOIN完成且字段存在后再开窗。
窗口函数必须在 JOIN 之后执行，否则 PARTITION BY 字段可能不存在、为 NULL 或重复，导致结果完全不可信。
为什么不能先开窗再 JOIN
窗口函数不改变行数，只在已有结果集上添加计算列；它依赖 JOIN 后的完整宽表。如果先对单表开窗（比如 ROW_NUMBER() OVER (PARTITION BY user_id)），而 user_id 实际来自另一张表、尚未 JOIN 进来，那这个 PARTITION BY 就是空转——数据库可能报错，也可能静默返回全表连续序号。
- 常见错误写法：
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time) FROM orders JOIN users ON orders.user_id = users.id—— 看似合理，但若orders表里字段名其实是customer_id，JOIN 后根本没生成user_id列，这个开窗就毫无意义 -
EXPLAIN能帮你确认执行顺序：必须看到JOIN步骤在WINDOW之前，且PARTITION BY字段出现在最终输出列中 - MySQL 8.0+、PostgreSQL、SQL Server 都严格遵循
FROM → JOIN → WHERE → WINDOW顺序，不支持反向操作
LEFT JOIN 后 PARTITION BY 字段为 NULL 怎么办
LEFT JOIN 未匹配的记录会让关联字段（如 user_id）变成 NULL，而所有 NULL 会被窗口函数归入同一组——COUNT(*) OVER (PARTITION BY user_id) 会把全部无用户订单算作“1 组”，统计彻底失真。
- 加
WHERE user_id IS NOT NULL过滤掉 NULL 行（适合业务允许丢弃左表空匹配） - 用
COALESCE(user_id, -1)把 NULL 映射成独立值，避免污染有效分区 - 优先改用
INNER JOIN，除非业务明确要求保留左表无关联记录 - 若必须保留 NULL 且需排序，用
ORDER BY created_at DESC NULLS LAST（PostgreSQL/Oracle）或COALESCE(created_at, '1970-01-01')兜底
一对多 JOIN 导致窗口结果虚高
右表存在一对多关系（如一个用户对应多条地址、多个状态快照），又没预处理就直接 JOIN，会产生冗余行——窗口函数会在这些重复行上照样计算，SUM() OVER 翻倍、ROW_NUMBER() 序号错乱。
- 正确做法是在 JOIN 前用子查询或 CTE 收拢右表：
SELECT * 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 -
ORDER BY必须带确定性：秒级时间戳相同就补order_id DESC，否则ROW_NUMBER()结果不稳定 - 别用
RANK()或DENSE_RANK()取最新行，它们对并列值分配相同序号，rn = 1可能返回多行
最易被忽略的是：窗口函数不能出现在 WHERE 或 ON 中，也不能和普通聚合函数（如 SUM()、COUNT()）混用在同一级 SELECT —— 这是语法硬限制，不是优化建议。一旦写成 SELECT order_id, SUM(amount), AVG(amount) OVER (PARTITION BY status)，多数数据库会直接报错。
