null在order by中无统一默认位置，sql:2003未作强制规定；postgresql/oracle/sql server默认视null为“最大值”，升序排末尾，mysql 5.7+则视其为“最小值”，升序排开头。
NULL在ORDER BY中没有统一默认位置
SQL标准（SQL:2003）对ORDER BY中NULL的排序位置**未作强制规定**，导致各数据库自行实现：PostgreSQL、Oracle、SQL Server默认把NULL当作“最大值”，升序时排末尾；MySQL 5.7+ 默认当作“最小值”，升序时排开头。同一句SELECT * FROM t ORDER BY col在不同库跑，NULL可能在第一行，也可能在最后一行。
GROUP BY后ORDER BY字段为NULL时分组不可见但实际存在
当GROUP BY category而category含NULL，这些记录会被聚合成一个独立分组，但该分组在最终结果中的物理顺序完全由数据库引擎决定——它不参与字典序比较，也不受category ASC隐式约束。你看到的“NULL分组突然跳到最前”不是bug，是未定义行为的自然体现。
- 显式控制位置：用
ORDER BY category IS NULL, category（NULL置前）或ORDER BY category IS NULL DESC, category（NULL置后） - 重命名需求：用
CASE WHEN category IS NULL THEN 'Uncategorized' ELSE category END替代原字段参与GROUP BY和ORDER BY - 注意：MySQL中
category IS NULL返回整数1/0，可直接排序；PostgreSQL中布尔值FALSE ，无需转换
多字段排序时NULL会干扰优先级链
写ORDER BY a, b DESC本意是“先按a升序，a相同时再按b降序”，但如果a为NULL的行数量很多，这些行之间b的排序就完全失效——因为NULL = NULL不成立，数据库不会进入“a相同”的分支逻辑，所有a IS NULL的行只靠默认NULL位置规则粗略排布。
- 真实业务中更常见的是“有效数据优先”，此时应拆成两层：先用
a IS NULL分离空/非空，再分别排序 - 错误写法：
ORDER BY a, b DESC→NULL组内b无序 - 正确写法：
ORDER BY a IS NULL, a, b DESC→ 先确保非NULL在前，再逐级细化 - 窗口函数同理：
PARTITION BY region, status中任一字段为NULL，都可能导致分区边界模糊，尤其当status大量为NULL时，region的区分度被稀释
跨库兼容写法为什么必须绕开NULLS FIRST/LAST
NULLS FIRST和NULLS LAST虽是SQL标准语法，但MySQL至今（8.0.33）仍不支持。硬写ORDER BY col NULLS LAST在MySQL里直接报错ERROR 1064。所以生产环境若需兼容多库，不能依赖该语法。
- 通用替代方案：
ORDER BY col IS NULL, col（升序且NULL置后）或ORDER BY col IS NULL DESC, col（NULL置前） - MySQL专用技巧：
ORDER BY ISNULL(col), col效果等价，但ISNULL()在PostgreSQL中不存在，会报错 - SQLite可用
col IS NULL，Oracle也支持，但Oracle还支持NULLS LAST——这意味着你得根据databaseId动态拼SQL，或在应用层做适配
真正容易被忽略的点是：哪怕只用一个数据库，只要未来有迁移计划，或者用了读写分离（主库PostgreSQL + 从库MySQL），这种隐式依赖默认行为的ORDER BY就会立刻暴露——结果不一致往往出现在上线后报表对不上，而不是开发阶段。
