窗口函数必须在JOIN之后执行，因它依赖JOIN生成的完整宽表，且不改变行数、只添加计算列；若PARTITION BY字段在JOIN后缺失、为空或重复，会导致分区错乱、NULL聚集或统计虚高。
窗口函数必须在JOIN之后执行
窗口函数不改变行数，只在已有结果集上添加计算列，所以它必须等JOIN拼出完整宽表后再运行。如果先对单表开窗再JOIN，PARTITION BY字段可能还没从另一张表引入，导致分区错乱或NULL值聚集。
常见错误写法：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而非user_id，或者JOIN后user_id出现大量重复或NULL，窗口结果就不可信。
- 执行顺序固定为：
FROM → JOIN → WHERE → WINDOW - 务必检查JOIN后用于
PARTITION BY的字段是否真实存在、非空、类型一致 - 用
EXPLAIN确认执行计划中没有意外的全表扫描，尤其当该字段无索引时
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，会产生冗余行——窗口函数会在这些重复行上照样计算，导致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 -
ORDER BY必须带确定性：秒级时间戳相同就补order_id DESC - 若业务允许多个“最新”并列，用
RANK()更合适；要唯一编号才强制ROW_NUMBER()
COUNT(*) + JOIN为什么总出错？用COUNT() OVER替代
直接在JOIN后写COUNT(*)会触发聚合语义冲突：要么报错（如PostgreSQL提示column must appear in the GROUP BY clause），要么因行膨胀导致结果翻倍（1个订单×3条明细=3行，COUNT(*)就返回3）。
正确解法是把统计逻辑挪到窗口函数里：
- 统计每个用户的原始订单数：
COUNT(*) OVER (PARTITION BY user_id)不行——它统计的是JOIN后的行数；应先在orders表里用CTE算好频次再JOIN - 若已JOIN且想按用户统计关联后行数，明确写
COUNT(*) OVER (PARTITION BY u.id)，但得接受这是“该用户在宽表里占多少行” - 避免
COUNT(*) OVER ()漏写PARTITION BY，那会变成全表总数，所有行都一样 - 需要去重统计（如“该用户买过几个不同商品”）：用
COUNT(DISTINCT product_id) OVER (PARTITION BY user_id)，注意MySQL 8.0+/PostgreSQL支持，SQL Server需用子查询模拟
