null默认排序位置因数据库而异，直接决定窗口函数排名结果：postgresql/oracle升序默认nulls last、降序默认nulls first，mysql 8.0+升序默认nulls first、降序默认nulls last，sql server旧版不支持需case模拟；未显式指定nulls first/last会导致同一sql在不同库中排名错乱。
ORDER BY 中 NULL 默认位置不一致，直接决定排名顺序
窗口函数的排名（RANK()、ROW_NUMBER()、DENSE_RANK()）完全依赖 ORDER BY 生成的行序。而 NULL 在排序中不参与比较，数据库只能按预设规则安置它——这个规则各不相同：PostgreSQL 和 Oracle 升序时默认 NULLS LAST，降序时默认 NULLS FIRST；MySQL 8.0+ 升序默认 NULLS FIRST，降序默认 NULLS LAST；SQL Server 旧版本甚至不支持显式控制。结果就是同一段 SQL，在不同环境里跑出的排名可能差好几档。
没加 NULLS LAST/FIRST，业务逻辑就可能崩
典型错误场景：按 updated_at DESC 取最新记录，但部分行 updated_at IS NULL。在 PostgreSQL 里，这些 NULL 行会被排到最后，ROW_NUMBER() OVER (ORDER BY updated_at DESC) 不会把它标为 1；但在 MySQL 8.0+ 里，NULL 默认排最后（即“最小值”），DESC 下反而被压到最前，ROW_NUMBER() 直接给它赋值 1 —— 系统误判为“最新数据”。这种错位不是偶发，是确定性行为差异。
- 升序排名（如按分数从低到高）要防 NULL 挤进第一名，得写
ORDER BY score ASC NULLS LAST - 降序排名（如销售额从高到低）要防 NULL 占高位，必须写
ORDER BY sales DESC NULLS LAST - 多字段排序时，
NULLS LAST只作用于紧邻它的字段，比如ORDER BY dept ASC NULLS FIRST, salary DESC NULLS LAST，不能只写一次放在末尾
NULL 参与计算链会传播中断，导致排名后字段全为 NULL
排名本身不因 NULL 报错，但后续依赖排名结果的计算极易断裂。例如你写 RANK() OVER (...) + COALESCE(some_col, 0)，只要 some_col 是 NULL，整条表达式就是 NULL —— 即便排名数字正常。更隐蔽的是帧计算：AVG(score) OVER (ORDER BY updated_at DESC ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING)，如果 updated_at 大量为 NULL 且未约束位置，窗口可能把时间上不相关的两行拉进来平均，结果完全失真。
- 所有参与算术、拼接、比较的列，先用
COALESCE(col, 0)或CASE WHEN col IS NULL THEN ... END转义 - 涉及
LAG()/LEAD()的场景，若需跳过 NULL，PostgreSQL 16+ 和 BigQuery 支持LAG(col) IGNORE NULLS；MySQL/SQL Server 必须用ROW_NUMBER()配合自连接模拟 -
COUNT(*) OVER ()统计总行数（含 NULL 行），COUNT(col) OVER ()只统计非 NULL 值个数——别混淆两者语义
WHERE 条件无法直接过滤排名结果，子查询里 NULL 排序照样生效
新手常写 SELECT *, RANK() OVER (ORDER BY score DESC) rnk FROM t WHERE rnk ，报错 <code>column "rnk" does not exist。因为 SQL 执行顺序中 WHERE 在窗口函数计算前就执行了。正确做法是套一层子查询或 CTE，但很多人忽略：子查询里 ORDER BY 的 NULL 处理逻辑依然生效。也就是说，你写了 CTE 却没在 OVER() 里加 NULLS LAST，排名还是错的。
- CTE 或子查询只是语法糖，不改变窗口函数内部的排序行为
- 测试时务必插入含 NULL 的测试数据，而不是只用干净样本验证
- 分区键（
PARTITION BY）写错会导致 NULL 行被错误分组，比如按部门排名时漏写PARTITION BY dept_id，所有 NULL 部门的记录会被归入同一组而非各自独立计算
NULLS LAST、不提前转义、不验证子查询层级里的排序逻辑，等于主动放弃结果一致性。
