在PostgreSQL中，NULLS FIRST生效需写为“ORDER BY col ASC NULLS FIRST”或“ORDER BY col DESC NULLS FIRST”，必须显式指定ASC/DESC且NULLS FIRST紧跟其后；仅写ORDER BY col NULLS FIRST会报错。
NULLS FIRST在ORDER BY中到底怎么写才生效
PostgreSQL默认把NULL当作“最大值”处理，所以ORDER BY col ASC时NULL会排在最后，DESC时反而排最前。想让NULL固定出现在开头，必须显式加上NULLS FIRST——光写ORDER BY col ASC NULLS FIRST还不够，得确认你用的是PostgreSQL 8.3+（老版本不支持），而且不能漏掉ASC或DESC关键字。
常见错误是只写ORDER BY col NULLS FIRST，这时PostgreSQL会报错：ERROR: syntax error at or near "NULLS"，因为NULLS FIRST必须跟在排序方向后面。
-
ORDER BY col ASC NULLS FIRST：非空值升序，NULL全堆最前 -
ORDER BY col DESC NULLS FIRST：非空值降序，NULL仍最前 -
ORDER BY col DESC NULLS LAST：等价于默认行为（NULL排末尾）
多字段排序时NULLS FIRST作用范围是单个表达式
当ORDER BY里有多个字段，比如ORDER BY status ASC NULLS FIRST, created_at DESC NULLS LAST，每个字段的NULLS FIRST/LAST是独立生效的，不会互相影响。这点容易被忽略——有人以为加一次NULLS FIRST就能管住所有字段，结果发现第二个字段的NULL还是按默认规则排。
典型场景：查工单列表，希望status为空的排最前（待分配），而created_at为空的工单（数据异常）要排在该状态组的最后。这时就得分别控制：
ORDER BY status ASC NULLS FIRST, created_at DESC NULLS LAST
索引是否能加速NULLS FIRST查询
如果经常用col ASC NULLS FIRST排序，普通B-tree索引（如CREATE INDEX idx ON tbl(col)）无法直接支持，因为索引默认按NULLS LAST逻辑组织。必须创建带显式NULLS FIRST的索引：
CREATE INDEX idx_col_asc_nulls_first ON tbl(col ASC NULLS FIRST);
否则即使写了NULLS FIRST，PostgreSQL也可能放弃走索引，改用排序（Sort节点），尤其在数据量大时明显变慢。验证方法：用EXPLAIN看执行计划里有没有Index Scan，而不是Sort + Seq Scan。
- 索引方向（
ASC/DESC）和NULLS策略必须与查询完全一致，差一个就用不上 -
col DESC NULLS LAST查询可以用col DESC普通索引，但col DESC NULLS FIRST必须另建索引
与其他数据库的NULL排序行为差异
PostgreSQL的NULLS FIRST是SQL标准语法，但MySQL、SQL Server根本不认这个子句；SQLite虽支持，但默认把NULL当最小值（和PG相反）。写跨数据库兼容SQL时，如果必须处理NULL位置，得用CASE WHEN模拟：
ORDER BY CASE WHEN col IS NULL THEN 0 ELSE 1 END, col ASC
但这会拖慢性能，且丢失原生NULLS FIRST的语义清晰性。真要兼容，优先考虑应用层排序，或者接受不同数据库的默认行为差异——毕竟多数业务场景里，NULL占比低，影响有限。
真正麻烦的是迁移旧系统时没意识到PG对NULL的默认排序逻辑和Oracle/SQL Server相反，上线后列表顺序突变，用户投诉“数据乱了”，其实只是NULL从末尾跑到开头而已。
