ORDER BY 中 NULL 默认排序不一致会导致窗口函数结果错乱，应显式使用 NULLS LAST/FIRST；PostgreSQL/Oracle 原生支持，SQL Server 需 CASE 模拟，MySQL 8.0+ 支持但需注意版本与隐式转换陷阱。
ORDER BY 中 NULL 值默认排最前，导致窗口函数结果错乱
SQL 窗口函数（如 ROW_NUMBER()、RANK()、LEAD()）的排序行为完全依赖 ORDER BY 子句。而多数数据库（PostgreSQL、Oracle、SQL Server）默认把 NULL 当作“最小值”，排在非空值之前；但 MySQL 8.0+ 默认当作“最大值”——这种不一致会让同一段窗口逻辑在不同环境产出不同结果。
典型现象：按 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 FIRSTforASC,NULLS LASTforDESC），看似正常实则隐患
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 版本并启用标准模式。
