PostgreSQL中NULLS LAST/FIRST用于显式控制NULL排序位置，需紧跟单个排序项后；跨库可用(col IS NULL)表达式模拟；复合排序中各字段NULL处理独立；索引需完全匹配ORDER BY才生效。
PostgreSQL 中 NULLS LAST 和 NULLS FIRST 的基本用法
PostgreSQL 默认把 NULL 当作“最大值”处理，所以 ORDER BY col ASC 时 NULL 排在最后，DESC 时排在最前。但这个行为不是 SQL 标准，也不被所有数据库支持——只有显式写上 NULLS LAST 或 NULLS FIRST 才能跨数据库可预期地控制 NULL 位置。
用法很简单：紧跟在单个排序项之后，和 ASC/DESC 同级：
SELECT * FROM users ORDER BY last_login DESC NULLS LAST;
注意：NULLS FIRST/LAST 必须跟在字段+方向之后，不能单独写，也不能放在整个 ORDER BY 末尾。
MySQL 和 SQL Server 不支持 NULLS FIRST/LAST 怎么办
MySQL（8.0+）和 SQL Server 实际上也支持 NULLS FIRST/LAST，但默认兼容旧模式，需要确认是否启用标准 SQL 模式。更稳妥的跨库写法是用表达式模拟：
- 想让
NULL排最前：ORDER BY (col IS NULL) DESC, col - 想让
NULL排最后：ORDER BY (col IS NULL), col
原理是 col IS NULL 返回布尔值（TRUE/FALSE），在排序中等价于 1/0。MySQL、PostgreSQL、SQL Server 都支持这种写法，SQLite 也行。不过要注意：如果 col 是字符串或日期类型，第二级排序仍需考虑类型隐式转换风险。
NULLS LAST 在复合排序中的优先级容易被忽略
在多个字段排序时，NULLS FIRST/LAST 只作用于它前面那个字段，不是全局设置。比如：
ORDER BY a ASC NULLS LAST, b DESC NULLS FIRST
这里 a 的 NULL 被推到最后，b 的 NULL 被提到最前，互不影响。常见错误是以为写了 NULLS LAST 就能“统一处理所有 NULL”，结果发现第二个字段的 NULL 还是按默认规则排了。
另一个易错点：如果用 COALESCE(a, 'zzz') 替代 NULLS LAST，虽能绕过语法限制，但会改变原始值参与比较的语义——比如 COALESCE(created_at, '9999-12-31') 可能让一个真实存在的未来时间被误判为“补位值”，排序逻辑就偏了。
索引能否加速 NULLS LAST 查询
可以，但必须匹配。PostgreSQL 允许在索引定义中包含 NULLS FIRST 或 NULLS LAST，例如：
CREATE INDEX idx_users_login_nulls_last ON users (last_login DESC NULLS LAST);
只有当查询的 ORDER BY 子句和索引定义完全一致（包括方向和 NULLS 选项），才会走索引。漏掉 NULLS LAST 或写成 NULLS FIRST，哪怕其他都对，优化器也会放弃该索引。
另外，如果表里 NULL 占比极高（比如 >80%），即使有索引，执行计划也可能退化为顺序扫描——因为跳过大量 NULL 行的成本可能高于全扫。
