窗口函数中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）中提前剔除，而不是靠排序甩到最后。
