NULL值默认位置不固定，取决于数据库：PostgreSQL和SQL Server/Oracle默认末尾，MySQL 8.0+默认开头；必须用NULLS FIRST/LAST显式控制，或用COALESCE/CASE兜底确保跨库一致性。
ORDER BY 子句中 NULL 值默认排在哪？
SQL 窗口函数（如 ROW_NUMBER()、RANK()、LAG()）的排序行为直接受 ORDER BY 子句影响，而 NULL 的位置不是固定的——它取决于数据库实现和显式设置。PostgreSQL 默认把 NULL 排在末尾，MySQL 8.0+ 默认排在开头，SQL Server 和 Oracle 则默认按“NULLS LAST”处理（但需确认版本）。不显式声明，结果就不可靠。
-
ORDER BY col ASC不保证 NULL 统一位置，不同引擎表现不一致 - 必须用
NULLS FIRST或NULLS LAST显式控制（PostgreSQL/Oracle/SQL Server 支持；MySQL 8.0+ 支持；SQLite 不支持） - 如果目标库不支持
NULLS子句（如旧版 MySQL），得用表达式兜底，比如ORDER BY ISNULL(col), col
用 COALESCE 或 CASE 把 NULL 转成可控值
当数据库不支持 NULLS FIRST/LAST，或你想让 NULL 在逻辑上“等于某个哨兵值”参与排序时，用 COALESCE 最直接：
-
ORDER BY COALESCE(date_col, '1970-01-01')：把 NULL 当作最早日期排最前 -
ORDER BY COALESCE(score, -9999)：数值字段用极小值垫底 - 注意类型必须一致：
COALESCE(col, 0)对字符串字段会报错，得用COALESCE(col, '')
更灵活的写法是 CASE：
ORDER BY CASE WHEN col IS NULL THEN 0 ELSE 1 END, col这样先按是否为 NULL 分组，再按真实值排序，兼容性最好，所有主流 SQL 引擎都支持。
窗口函数里 NULL 排序影响分组和偏移函数结果
LAG()、LEAD()、FIRST_VALUE() 这类函数依赖排序顺序，如果 NULL 挤在中间或开头，可能意外改变“前一行”的归属：
- 若
ORDER BY status NULLS LAST，则状态为 NULL 的记录总在最后，LAG(status)取到的是上一个非 NULL 值（或 NULL） - 若没控制 NULL 位置，同一查询在不同库跑出不同
ROW_NUMBER()序号，下游分页或去重逻辑就崩了 -
RANK()和DENSE_RANK()对 NULL 会视为相同值——只要两个 NULL 相邻，它们就得共享同一个排名，这点容易被忽略
真正麻烦的不是语法怎么写，而是团队共用一套 SQL 脚本时，有人在 PostgreSQL 上测试通过，部署到 MySQL 就发现分页错位、TOP N 结果不一致——根源往往就是这一行没写 NULLS LAST，或者用了 COALESCE 却没校验字段类型。
