sql标准未定义null默认位置，主流数据库行为不一：postgresql/oracle默认nulls first，mysql 5.7+默认asc时null最前、desc时最后，sql server asc时null最前、desc时最后；必须显式用nulls first/last或case模拟确保一致性。
ORDER BY 子句里 NULL 值默认排在哪？
SQL 标准规定，NULL 在升序（ASC）时排在最前，降序（DESC）时排在最后——但这是可配置的，而且不同数据库默认行为不一致。PostgreSQL 遵守标准，MySQL 8.0+ 和 SQL Server 也支持显式控制，而旧版 MySQL（5.7）会把 NULL 当作最小值处理，导致 ROW_NUMBER() 或 RANK() 排序结果和预期不符。
-
ORDER BY col ASC NULLS FIRST：显式声明，兼容性好（PostgreSQL、Oracle、SQL Server 2022+、MySQL 8.0+） -
ORDER BY col ASC NULLS LAST：更常见于业务场景（比如“有效数据优先编号”） - MySQL 5.7 不支持
NULLS FIRST/LAST，得用IF(col IS NULL, 1, 0)拆成两层排序
窗口函数里用 COALESCE 处理 NULL 会改变语义吗？
会，而且很隐蔽。COALESCE(col, 0) 或 COALESCE(col, '') 看似“填空”，实则把缺失值强行映射到一个具体值，可能让原本不该并列的行获得相同排序键，进而影响 RANK()、DENSE_RANK() 的分组逻辑。
- 如果目标是“NULL 排末尾，但不干扰真实值顺序”，别用
COALESCE，改用排序修饰符（如上） - 如果字段是数值型且业务上
0和NULL含义不同（比如“未填写” vs “零销量”），COALESCE会混淆语义 - 真要兜底，优先考虑
CASE WHEN col IS NULL THEN 'ZZZZ' ELSE col END（字符串）或CASE WHEN col IS NULL THEN 999999999 ELSE col END（数值），再配合ASC，比COALESCE更可控
ROW_NUMBER() 和 RANK() 对 NULL 的敏感度一样吗？
不一样。ROW_NUMBER() 只依赖排序稳定性，只要 ORDER BY 能区分行，它就给唯一编号；而 RANK() 和 DENSE_RANK() 会在排序键相等时赋予相同排名——所以当多个 NULL 出现在同一窗口中，它们会被视为“相等键”，直接触发并列排名。
- 例如：
RANK() OVER (ORDER BY score DESC)中，3 个NULL会一起拿到第 1 名，下一个非NULL值是第 4 名（跳过 2、3） - 若想避免跳名次，用
DENSE_RANK()；若要强制唯一编号，用ROW_NUMBER()并在ORDER BY里加二级排序（如ORDER BY score DESC, id ASC） - 关键点：窗口函数本身不“处理”
NULL，它只忠实地执行你写的ORDER BY逻辑
分区后各组内 NULL 行的排序是否独立？
是的，每个 PARTITION BY 组内的排序是独立计算的，但 NULL 的位置规则仍由该组内的 ORDER BY 决定。容易忽略的是：如果分区键本身含 NULL，某些数据库（如旧版 Hive）可能把所有 NULL 分区键归为同一组，导致跨业务逻辑的聚合错误。
- 显式过滤：
WHERE partition_col IS NOT NULL最安全 - 或补全分区键：
COALESCE(partition_col, 'UNKNOWN')，但需确认业务是否接受该占位符 - 窗口定义中不要依赖未声明的隐式排序，
ORDER BY必须明确写出，否则ROW_NUMBER()结果不可预测
实际写法里，最容易被绕进去的是以为加了 NULLS LAST 就万事大吉，却忘了底层数据库版本不支持，或者没意识到 RANK() 在多个 NULL 下天然跳号——这些细节不验证执行计划或小样本数据，上线后才暴露。
