PostgreSQL中ORDER BY默认不保证NULL位置，必须显式声明NULLS LAST或NULLS FIRST；ASC默认NULLS FIRST、DESC默认NULLS LAST，但属实现细节而非SQL标准，跨库或UNION时易出错。
PostgreSQL中ORDER BY默认不保证NULL位置，必须显式声明
PostgreSQL的ORDER BY在升序（ASC）时默认把NULL排在最前，降序（DESC）时排在最后——但这只是默认行为，**不是标准SQL保证**，且容易被误以为“天然如此”。实际在跨数据库迁移或配合UNION等场景下，NULL位置可能意外变动。要稳定实现NULLS LAST，必须显式写出关键词。
直接在ORDER BY子句后加NULLS LAST即可生效
这是最常用、最直白的做法，语法清晰，无需函数包装或条件判断。注意它紧接在排序表达式之后，和ASC/DESC同级。
常见写法示例：
SELECT name, score FROM students ORDER BY score ASC NULLS LAST;
等价于“分数从小到大排，空分放最后”；而
SELECT name, score FROM students ORDER BY score DESC NULLS LAST;
表示“分数从大到小排，空分仍放最后”（即空分排在所有非空值之后，哪怕它们是最低分）。
要点：
-
NULLS LAST和NULLS FIRST是互斥选项，不能同时出现 - 可混合使用：例如
ORDER BY col1 ASC NULLS FIRST, col2 DESC NULLS LAST - 不写
NULLS FIRST/LAST时，PostgreSQL按ASC → NULLS FIRST、DESC → NULLS LAST隐式处理，但不可依赖
用COALESCE模拟NULLS LAST可能引入逻辑错误
有人会用COALESCE(score, -999999)把NULL转成极小值来“骗过”排序，这在ASC时看似让NULL靠后，但本质是篡改数据语义：
- 若字段本身允许负数（如温度、金融损益），
-999999可能比真实值还小，破坏业务含义 - 索引无法有效支持
COALESCE(score, ...)表达式，导致排序走全表扫描 - 与
NULLS LAST语义不同：前者是“把NULL当-999999排”，后者是“NULL不参与比较，统一归置到最后”
除非有特殊兼容性要求（比如老版本PostgreSQL NULLS FIRST/LAST），否则不要用COALESCE替代原生语法。
注意pg_dump、视图、物化视图中的排序持久性
NULLS LAST只影响查询执行时的行序，它不会被保存进视图定义（除非显式写在CREATE VIEW的SELECT中），也不会改变表结构或索引行为。
特别容易忽略的点：
-
pg_dump --inserts导出的数据插入顺序，不继承原表ORDER BY，更不保留NULLS LAST - 物化视图刷新后，数据物理存储顺序仍由底层堆页决定，
ORDER BY仅作用于查询时 - 如果依赖严格顺序做分页（如
LIMIT/OFFSET），必须每次查询都带完整ORDER BY ... NULLS LAST，不能省略
真正需要物理有序，得靠CLUSTER或CREATE INDEX ... ORDER BY（仅限B-tree索引支持NULLS FIRST/LAST声明）。
