SQL窗口函数：PARTITION BY与ORDER BY的执行优先级与细节剖析
深入理解窗口函数，关键在于厘清其内部执行逻辑。一个核心规则是：PARTITION BY 先执行，ORDER BY 后执行。SQL引擎在处理窗口函数时，会首先依据 PARTITION BY 将数据划分为独立的子集，随后，在每个分区内部，再按照 ORDER BY 进行排序。这意味着，当没有 PARTITION BY 时，ORDER BY 的排序范围就是整张表；而一旦指定了分区，ORDER BY 就只在当前分区内生效，分区之间的数据顺序互不干扰。
窗口函数里 PARTITION BY 和 ORDER BY 谁先执行？
答案很明确：分区永远先于排序。这个顺序是理解窗口函数行为的基石。常见的误解是认为数据会先进行全局排序，然后再被划分到各个分区——实际情况恰恰相反。这也解释了为什么 ROW_NUMBER() OVER (ORDER BY score DESC) 会生成全表唯一的排名序号，而 ROW_NUMBER() OVER (PARTITION BY dept ORDER BY score DESC) 则会在每个部门内部重新从1开始编号。两者的结果截然不同，根源就在于执行顺序。
ORDER BY 缺失时，ROWS BETWEEN 行为不可靠
当窗口定义中省略了 ORDER BY 子句，却使用了像 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 这样的行帧（Frame）子句时，结果会变得不可预测。此时，帧边界的确定依赖于数据的物理存储顺序（例如堆表的插入顺序），这不仅在不同数据库间可能表现不一，甚至在同一数据库的不同执行计划下也可能发生变化。例如，PostgreSQL通常会直接报错，MySQL 8.0+ 允许但会发出警告，而SQL Server则会拒绝执行。
因此，一个重要的实践原则是：必须显式指定 ORDER BY，才能确保帧边界的语义稳定。哪怕只是简单地按主键排序（ORDER BY id），也比完全不写要可靠得多。这一点对于 RANGE 帧而言更为关键——在没有 ORDER BY 的情况下，数据库根本无法确定“等值范围”的边界。
PARTITION BY 字段含 NULL 时，所有 NULL 被归为同一组
这是一个符合ANSI SQL标准的行为，并非某个数据库的bug。虽然在三值逻辑中 NULL 不等于 NULL，但在 PARTITION BY 的语境下，所有 NULL 值会被视为“相同”并归入同一个分区。
举个例子：使用 PARTITION BY region 时，如果有多行数据的 region 字段为 NULL，那么这些行将共同组成一个独立的分区，并在这个分区内参与窗口计算。如果业务上需要将NULL视为一个独立的类别，或者希望将其排除在分区逻辑之外，通常需要在窗口函数外部提前处理，例如使用 CASE WHEN region IS NULL THEN 'UNKNOWN' ELSE region END 进行转换。
值得注意的是，这一处理逻辑与 GROUP BY 对 NULL 值的处理方式是一致的。但在进行累计求和（SUM OVER）等计算时，这个细节容易被忽略，可能导致意料之外的数据聚合。
多字段 ORDER BY 影响 RANK() 和 DENSE_RANK() 的并列判断
RANK() 和 DENSE_RANK() 函数判断“并列”的唯一依据，是 ORDER BY 后面所有列的值是否完全相等。例如，ORDER BY dept, salary 意味着只有在部门和薪水都相同的情况下，行与行之间才会被视为并列；而如果只是 ORDER BY salary，那么只要薪水相同就会产生并列，与部门无关。
基于此，有几个实用的建议：
- 明确业务需求：仔细审视业务上对“并列”的定义，是否真的需要多个字段联合判断。
- 慎用高基数字段：避免在
ORDER BY列表中加入像id这样的高基数（几乎唯一）字段，否则几乎不会出现并列情况，导致RANK()的行为退化为ROW_NUMBER()。 - 直观验证：在测试时，直接使用
SELECT *, RANK() OVER (ORDER BY x, y) AS r这样的语句，观察重复值对应的排名r是否符合预期，这是最直接的验证方法。
最后，还有一个容易被混淆的概念：窗口函数的执行阶段是独立于查询最外层的 ORDER BY 的。外层查询的 ORDER BY name 只影响最终结果的展示顺序，而完全不会改变窗口函数内部（即 OVER 子句中）定义的排序逻辑。切勿指望通过最终的结果排序来“修正”窗口计算得出的顺序。
