窗口函数中order by必须置于over()内以定义窗口内行处理顺序，漏写会导致不可控结果；partition by与order by共同决定动态窗口边界，三者缺一不可。
窗口函数里 ORDER BY 写错位置，结果就全乱了
窗口函数的排序逻辑不是“先分组再排序”，而是“在每个分组内按指定顺序累积计算”。ORDER BY 必须出现在 OVER() 里，且它决定的是窗口内行的处理顺序——哪怕你只想要分组聚合，没写 ORDER BY，某些数据库（如 PostgreSQL）会默认按物理顺序，MySQL 8.0+ 则要求显式声明或报错。
-
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)：每部门内按薪资降序编号 - 如果漏掉
ORDER BY，ROW_NUMBER()仍能执行，但编号顺序不可控；而LEAD()、LAG()、AVG() OVER (... RANGE ...)会直接报错或返回意外值 - 注意：
PARTITION BY和ORDER BY的字段类型要兼容，比如用字符串字段ORDER BY时间戳列，可能隐式转换失败
RANK()、DENSE_RANK()、ROW_NUMBER() 区别不止是“并列怎么算”
三者在遇到相同排序值时的编号策略不同，但更关键的是它们对后续计算的影响——尤其是当你把排名结果再用于过滤或连接时。
-
ROW_NUMBER()：严格递增，无重复，适合取“每组第 N 条”（如 Top 3） -
RANK()：并列后跳号（1,1,3），适合强调名次层级，但WHERE rank = 2可能查不到数据（若前两名并列） -
DENSE_RANK()：并列不跳号（1,1,2），适合分档（如前 2 名、3–5 名），但要注意它不保证每档行数稳定 - 性能上无本质差异，但
RANK()和DENSE_RANK()需额外做等值判断，大数据量下略慢于ROW_NUMBER()
用 GROUP BY + 聚合函数替代窗口函数？小心逻辑错位
有人看到“分组求最大值”就想用 GROUP BY，但窗口函数的核心价值是保留原始行粒度。一旦用了 GROUP BY，你就丢掉了明细数据。
- 想查“每个部门薪资最高的人及其姓名”，用
MAX(salary) OVER (PARTITION BY dept)可以和原表所有字段共存；而GROUP BY dept只能返回部门和最高薪，拿不到对应员工姓名（除非加子查询或JOIN） -
GROUP BY无法表达“截止到当前行的累计销售额”，而SUM(sales) OVER (PARTITION BY region ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)可以 - 混合使用时注意：窗口函数不能出现在
WHERE或GROUP BY子句中，只能在SELECT或HAVING（部分数据库支持）里用
MySQL 8.0 / PostgreSQL / SQL Server 的 OVER() 兼容性坑
语法看着一样，但细节行为差异足以导致线上翻车。
- MySQL 8.0 不支持
ROWS BETWEEN ... PRECEDING AND UNBOUNDED FOLLOWING这种反向范围，必须重写逻辑；PostgreSQL 支持，但默认RANGE模式对时间字段可能隐式扩展 - SQL Server 的
OFFSET-FETCH和窗口函数混用时，ORDER BY必须完全一致，否则报错；MySQL 则允许不同 - PostgreSQL 中
NULLS FIRST/LAST是可选项，MySQL 8.0 默认NULLS LAST，且不支持显式声明；这会导致ORDER BY score DESC在含空值时排序结果不一致 - 所有数据库对
OVER()中未指定PARTITION BY的情况，都视作整张表为一个分区——但若表数据量大，这个“全局窗口”容易触发内存溢出（尤其LAG()跨数千行）
PARTITION BY 划分桶，ORDER BY 排序轴，ROWS/RANGE 定义滑动范围，三者缺一不可，改任意一个，结果集的语义就变了。
