如何通过NULLS LAST语法巧妙解决SQL窗口函数中NULL值排序难题？

本文共计855个文字，预计阅读时间需要4分钟。

SQL窗口函数（如 ROW_NUMBER()、RANK()、LEAD()）的排序行完全依赖于 ORDER BY 子句。大多数数据库（如PostgreSQL、Oracle、SQL Server）默认将 NULL 当作最小值，排在非空值之前；但MySQL 8.0+ 默认将 NULL 当作最大值。这种不一致性会导致相同窗口逻辑在不同环境产生不同结果。

典型现象：按 updated_at 降序取最新记录时，含 NULL 的行意外排第一，ROW_NUMBER() OVER (ORDER BY updated_at DESC) 把 NULL 行标为 1，业务误判为“最新”。

• 必须显式声明 NULLS LAST（升序时用 NULLS FIRST），不能依赖默认行为
• PostgreSQL 和 Oracle 原生支持；SQL Server 需用 IS NULL 补丁；MySQL 8.0+ 支持但需确认版本
• NULLS LAST 是 SQL:2003 标准，但 SQLite 目前不支持（v3.45 仍报错）

PostgreSQL / Oracle 中正确写法：直接加 NULLS LAST

这两者对标准支持最完整，语法干净：

SELECT id, status, ROW_NUMBER() OVER (ORDER BY updated_at DESC NULLS LAST) AS rn FROM orders;

注意：NULLS LAST 必须紧跟在排序表达式之后，不能放在整个 ORDER BY 末尾；多个字段排序时，每个字段可独立指定：

• ORDER BY category ASC NULLS FIRST, updated_at DESC NULLS LAST
• 混合方向下，NULLS FIRST/LAST 仅作用于其前一个表达式
• 若漏写，PostgreSQL 仍会执行但按默认规则（NULLS FIRST for ASC, NULLS LAST for DESC），看似正常实则隐患

SQL Server 兼容方案：用 CASE + IS NULL 模拟

SQL Server 不支持 NULLS LAST，需手动把 NULL 映射为一个“足够大”的值：

SELECT id, status, ROW_NUMBER() OVER ( ORDER BY CASE WHEN updated_at IS NULL THEN 1 ELSE 0 END, updated_at DESC ) AS rn FROM orders;

原理是先按是否为 NULL 分组（NULL → 1，非空 → 0），再按真实值排序。关键点：

• 升序场景要反过来：先 CASE WHEN ... THEN 0 ELSE 1 END，再字段 ASC
• 时间字段可用 '9999-12-31' 替代，但需确保类型兼容且不越界
• 性能上多一次计算，大数据量时比原生 NULLS LAST 略慢（执行计划可见额外 Compute Scalar）

MySQL 8.0+ 注意隐式转换和版本陷阱

MySQL 自 8.0.1 起支持 NULLS LAST，但有两个坑：

• 开启 sql_mode = 'STRICT_TRANS_TABLES' 时，若排序字段有非法日期（如 '0000-00-00'），可能被转成 NULL，再被 NULLS LAST 拉到末尾——实际不是原始 NULL，而是转换产物
• 低版本（如 5.7）会直接报错 ERROR 1064 (42000): You have an error in your SQL syntax，必须升级或改用 IFNULL() 替代
• 示例兜底写法：ORDER BY IFNULL(updated_at, '1970-01-01') DESC（但会丢失真正 NULL 的语义）

真正需要区分“原始 NULL”和“缺省值”的场景，必须确认 MySQL 版本并启用标准模式。