SQL查询中将NULL值强制排序到结果末尾的方法

聊到SQL排序，NULL值的处理总是个容易踩坑的地方。默认情况下，MySQL和SQL Server把NULL当作“最小值”，所以升序排序时NULL排在最前面，降序时反而排到最后；而PostgreSQL和Oracle则正好相反。但业务需求往往是：非空值按正常顺序排列，NULL统一垫底。这可不是数据库默认能搞定的——得主动干预。

ORDER BY 中 NULL 值默认排序行为是什么？MySQL、PostgreSQL、SQL Server 默认把 NULL 当作“最小值”，所以 ORDER BY column ASC 时，NULL 会排最前；DESC 时反而排最后。但业务常要「非空值优先升序，NULL 统一垫底」，这不是默认能搞定的。

不同数据库对 NULLS FIRST/NULLS LAST 的支持情况也不一样：PostgreSQL 原生支持，MySQL 8.0+ 才加入，SQL Server 和更早版本的 MySQL 则完全不认——只能靠表达式绕过去。

用 CASE 表达式把 NULL 显式转为高优先级值这是兼容性最强、各数据库都支持的办法。核心思路：给 NULL 分配一个比所有合法值都大的排序权重。

比如按 price 升序，但要 NULL 排最后：

ORDER BY CASE WHEN price IS NULL THEN 1 ELSE 0 END, price

这段逻辑很清晰：

• CASE 先做分组——非 NULL 行给 0，NULL 行给 1，保证所有非空行排在前面；
• 第二级再按 price 正常升序，这时只对 price IS NOT NULL 的行生效；
• 如果字段是字符串，可以换成 THEN 'zzzzz'（确保字典序最大），但用数值标记最稳妥；
• 注意：CASE 表达式不能写在 SELECT 列表里再通过别名引用（部分数据库不支持），必须原样写进 ORDER BY。

MySQL 8.0+ 和 PostgreSQL 可用 NULLS LAST（但要注意语法位置）

这两个数据库支持标准 SQL 的 NULLS LAST，但语法位置有讲究——必须紧跟在列名和排序方向之后，不能甩到最后：

ORDER BY price ASC NULLS LAST

错误写法：ORDER BY price ASC, NULLS LAST（这会被当成第二排序列，直接报错）

常见陷阱要注意：

• MySQL 5.7 或更早版本写这个会直接报 ERROR 1064；
• PostgreSQL 里如果用了 DESC 再加 NULLS LAST，效果是“非空值降序，NULL 在末尾”，符合直觉；但通常你需要的是 ASC NULLS LAST 实现空值垫底；
• SQLite 不支持 NULLS LAST，碰到它只能回退到 CASE 方案。

避免用 COALESCE() 替代 NULL 处理排序

有人喜欢写 ORDER BY COALESCE(price, 999999)，看似简单，实际上隐患不少：

• 如果 price 是 DECIMAL(10,2)，填整数 999999 可能触发隐式类型转换，某些数据库会报警告甚至截断；
• 假如真实数据里真有 price = 999999，那它就会和 NULL 混在一起排序，逻辑直接崩了；
• 对字符串字段用 COALESCE(name, 'ZZZZZ') 同样危险——万一真有客户姓“ZZZZZ”呢？
• 更关键的是，COALESCE() 会破坏索引使用，如果字段上有索引（比如 INDEX(price)），表达式会让索引失效。

真正安全的边界处理，永远应该基于 IS NULL 判断，而不是塞个假值进去凑数。