聊到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 判断，而不是塞个假值进去凑数。
