窗口函数中ORDER BY对NULL的默认排序因数据库而异：Oracle/PostgreSQL默认NULLS FIRST，MySQL/SQL Server无原生支持且行为不一致；必须显式用NULLS LAST/FIRST或CASE/IF模拟，否则会导致RANK、帧范围及聚合逻辑错位。

窗口函数中排序列含 NULL 时，ORDER BY 默认行为会让结果不可控——必须显式用 NULLS LAST（或 NULLS FIRST）控制位置，否则排名、帧范围、聚合逻辑全可能错位。

为什么 NULL 在 ORDER BY 中会破坏窗口计算

窗口函数的 ORDER BY 不只是“排个序好看”，它直接决定窗口帧（如 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW）包含哪些行。而 NULL 的默认排序位置因数据库而异：

• PostgreSQL / Oracle：默认 NULLS FIRST（ASC 时排最前，DESC 时也排最前）
• MySQL 8.0：不支持 NULLS FIRST/LAST，且 NULL 在 ASC/DESC 下都排末尾（但行为不稳定，不建议依赖）
• SQL Server：类似 MySQL，无原生语法，需用 CASE WHEN col IS NULL THEN 1 ELSE 0 END 模拟

典型翻车场景：RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) 中，若某员工 salary 为 NULL，他可能被排在第一名（因 NULL 被当最大值），导致业务误判“高薪员工”。这不是函数 bug，是排序语义没对齐。

NULLS LAST 在 PostgreSQL 和 Oracle 中怎么写

语法简单，但位置严格：必须紧贴在单个排序表达式之后，不能放在整个 ORDER BY 末尾。

• 正确：ORDER BY sale_cnt DESC NULLS LAST
• 错误：ORDER BY sale_cnt DESC NULLS LAST, created_at ASC —— 第二个字段没指定 NULL 处理，行为未定义
• 多字段安全写法：ORDER BY sale_cnt DESC NULLS LAST, created_at ASC NULLS LAST

示例（Oracle/PostgreSQL）：

SELECT
  emp_id,
  dept_id,
  salary,
  RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC NULLS LAST) rnk
FROM employees;

这样能确保所有 salary IS NULL 的员工排在部门内最后，不会挤占真实薪资的名次。

MySQL 8.0 怎么模拟 NULLS LAST

MySQL 不认 NULLS LAST，硬写会报错 ERROR 1064。替代方案是把 NULL 映射成一个极值，让排序“骗过”默认逻辑：

• 升序时要 NULL 排最后：ORDER BY IF(salary IS NULL, 999999999, salary) ASC
• 降序时要 NULL 排最后：ORDER BY IF(salary IS NULL, -1, salary) DESC
• 更稳妥（兼容负数）：ORDER BY CASE WHEN salary IS NULL THEN 1 ELSE 0 END, salary DESC

注意：用 IF 或 CASE 会阻止索引下推，大数据量时可能影响性能；若该列有索引，优先考虑在应用层过滤 NULL 或补默认值。

容易被忽略的关键点

很多人加了 NULLS LAST 就以为万事大吉，但还有三个隐性坑：

• PARTITION BY 列本身为 NULL 时，这些行会被分到同一个“NULL 分区”里——如果业务上 NULL 表示“未知部门”，那这个分区就毫无意义，应提前用 COALESCE(dept_id, 'UNKNOWN') 归一化
• ROWS BETWEEN 帧定义受排序影响：若排序列大量为 NULL，CURRENT ROW 可能对应多行（因排序值相同），导致窗口重复计算
• CTE 或子查询中用了 NULLS LAST，外层再 ORDER BY 时不继承——每个 ORDER BY 都得单独写

真正稳的做法，不是“加了 NULLS LAST 就结束”，而是先确认：排序列的 NULL 代表什么业务含义？是否该参与排名？如果不该，就在 WHERE 或 FILTER（PostgreSQL）中提前剔除，而不是靠排序甩到最后。