PostgreSQL默认NULLS FIRST（ASC/DESC均排最前），SQL Server不支持NULLS LAST且无明确默认规则，ASC时NULL排最前、DESC时排最后；二者窗口函数中若未显式声明NULL位置，同一语句结果可能错位。
PostgreSQL默认NULLS FIRST，SQL Server默认NULL排最后
PostgreSQL对ORDER BY中NULL的处理是：ASC时NULLS FIRST（排最前），DESC时也NULLS FIRST（即排最前）；而SQL Server实际行为是ASC时NULL排最前、DESC时排最后——但**它不支持NULLS LAST语法，也不声明默认规则，纯靠引擎隐式行为**。这意味着同一段ROW_NUMBER() OVER (ORDER BY score DESC)在两库中可能把NULL行标为1或标为末尾，业务逻辑直接错位。
窗口函数里不写NULLS LAST，PostgreSQL照样执行但结果不可控
PostgreSQL支持NULLS LAST，但必须紧贴排序表达式后写，漏掉就走默认（NULLS FIRST）。常见错误包括：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 写成
ORDER BY score DESC NULLS LAST, updated_at ASC—— 正确，每个字段独立控制 - 写成
ORDER BY score DESC, updated_at ASC NULLS LAST—— 错误，score字段仍按默认NULLS FIRST排 - 在
RANK() OVER (ORDER BY status DESC)中status含NULL，没加NULLS LAST，导致“未知状态”被当成最高优先级排第一
SQL Server必须用CASE WHEN ... IS NULL模拟NULLS LAST
SQL Server不识别NULLS LAST，硬写会报错Incorrect syntax near 'NULLS'。安全写法是把NULL映射为极值：
- 升序要NULL排最后：
ORDER BY CASE WHEN score IS NULL THEN 1 ELSE 0 END, score ASC - 降序要NULL排最后：
ORDER BY CASE WHEN score IS NULL THEN 2147483647 ELSE score END DESC（注意别溢出） - 更稳妥：
ORDER BY CASE WHEN score IS NULL THEN 1 ELSE 0 END, score DESC—— 先分组再排序，避免数值陷阱
跨库迁移时最容易忽略的不是语法，而是排序语义绑定
同一个RANK() OVER (ORDER BY created_at DESC)在PostgreSQL里可能把NULL时间戳排第一（最新），在SQL Server里排最后（最旧）。这种差异不会报错，但会导致分页跳行、报表数据断层、ETL校验失败。真正要检查的不是“有没有写错函数”，而是“每个ORDER BY子句是否显式声明了NULL位置”——哪怕只有一处漏掉，整个窗口逻辑就不可靠。
