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声明）。