NULLS LAST显式固定NULL在排序中的位置，确保窗口函数行序稳定；PostgreSQL/Oracle默认NULL排最前，MySQL 8.0+默认排最后，SQL Server旧版不支持需CASE模拟。
NULLS LAST 直接决定窗口函数的行序稳定性
窗口函数如 ROW_NUMBER()、RANK()、DENSE_RANK() 的编号完全依赖 ORDER BY 子句生成的逻辑顺序。而 NULL 在排序中不参与值比较，数据库只能靠预设规则安置它——NULLS LAST 就是显式告诉引擎：“把所有 NULL 当作比任何非空值都小（升序时）或都大（降序时）”，从而固定其位置。
没加 NULLS LAST 时，不同库行为分裂：
- PostgreSQL / Oracle：默认
ORDER BY col DESC把 NULL 排第一（即“最大”），ROW_NUMBER()可能把 “部门为 NULL” 标为 1 - MySQL 8.0+：默认把 NULL 排最后，同一语句结果可能差三名
- SQL Server 2019 及更早：不支持该语法，直接报错，根本跑不起来
ORDER BY 中多个字段时，NULLS LAST 必须逐字段声明
NULLS LAST 不是作用于整个 ORDER BY 列表，而是绑定到它前面紧邻的排序表达式。写成 ORDER BY a ASC, b DESC NULLS LAST，只影响 b 列的 NULL 位置；a 列仍按数据库默认规则处理。
常见错误写法：
ORDER BY department NULLS LAST, salary DESC -- ✅ 正确：department 的 NULL 显式排最后 ORDER BY department, salary DESC NULLS LAST -- ❌ 错误：NULLS LAST 只管 salary，department 仍按默认走
多维排序下，只要任一字段含 NULL 且未约束位置，就可能导致同组内行序漂移，让 PARTITION BY 内的排名不可复现。
不支持 NULLS LAST 的数据库怎么安全模拟
MySQL 5.7、SQL Server 2019 等旧版本不能用 NULLS LAST，硬写会触发 ERROR 1064 或 Incorrect syntax near 'NULLS'。必须用 CASE WHEN 构造两级排序键：
- 升序 + NULL 最后：
ORDER BY CASE WHEN col IS NULL THEN 1 ELSE 0 END, col ASC - 降序 + NULL 最后：
ORDER BY CASE WHEN col IS NULL THEN 1 ELSE 0 END, col DESC
别用 IF(col IS NULL, 'ZZZZ', col) 这类字符串补位——万一 col 是数值型，隐式转换会出错；万一 col 原本就有 'ZZZZ' 值，就真乱序了。
窗口帧（ROWS/RANGE）受 NULL 排序影响更隐蔽
像 AVG(sales) OVER (ORDER BY updated_at DESC ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) 这种带帧的计算，如果 updated_at 大量为 NULL，又没加 NULLS LAST，那这些 NULL 行可能被挤到开头或中间，导致“前一行”和“后一行”实际不是时间上相邻的记录，平均值就完全失真。
这种情况不会报错，但结果偏离业务预期——尤其在监控类报表里，异常点常集中为 NULL，它们的位置一偏，整段滑动窗口就垮了。
