最直接可靠的方式是用 ORDER BY column_name IS NULL, column_name ASC：column_name IS NULL 返回 0（非空）或 1（空），升序使 0 在前、1 在后，从而非空值优先、NULL 值垫底，该写法跨 MySQL/PostgreSQL/SQLite 兼容。
ORDER BY 中用 IS NULL 表达式控制字段非空优先级
想让非空值排前面、NULL 值排后面，最直接可靠的方式是把 column_name IS NULL 当作一个布尔排序项：它返回 0（非空）或 1（空），再配合升序，就能天然实现“有效数据优先”。这个写法在 MySQL、PostgreSQL、SQLite 全部生效，不依赖版本特性。
- 别写
COALESCE(column_name, '9999-12-31')这类兜底值——时间假值会污染业务语义，比如导出报表时“最早创建时间”变成 9999 年 - 不要只靠
ORDER BY column_name ASC期望数据库自动把 NULL 排最后——MySQL 默认 NULL 最小（ASC 时在最前），PostgreSQL 默认 NULL 最大（ASC 时在最后），结果不可控 - 如果要“空值优先”，就改用
column_name IS NULL DESC，让1（空）排在0（非空）前面
CASE WHEN 实现多字段混合优先级（如 name > code > create_time）
当业务要求“名称匹配的排最前，没名称就看编码，都没就按时间”，就不能只靠 IS NULL；得用 CASE WHEN 给每行打一个优先级分，再按这个分排序。关键是每个分支必须返回同类型值（推荐整数），且必须覆盖所有情况（ELSE 不可省）。
- 漏写
ELSE→ 未匹配行返回NULL，默认排最前，常导致“时间最老的记录意外顶到顶部” - 类型不一致（比如有的
WHEN返回字符串，有的返回数字）→ 多数数据库会报错或隐式转换失败 - 示例：按
name、code、create_time三级优先展示：ORDER BY CASE WHEN name IS NOT NULL THEN 1 WHEN code IS NOT NULL THEN 2 ELSE 3 END, name, code, create_time DESC
NULLS FIRST/LAST 的兼容性陷阱
NULLS FIRST 和 NULLS LAST 看起来干净，但实际落地时容易翻车：MySQL 5.7 及更早版本不支持；SQL Server 2012+ 才开始支持；SQLite 直到 3.30.0（2020 年）才加入。线上环境若混用不同版本，同一段 SQL 可能一半报错、一半行为异常。
- MySQL 8.0+ 写
ORDER BY name ASC NULLS LAST没问题，但换成 MySQL 5.7 就直接语法错误 - PostgreSQL 支持完整语法，但如果你的 ORM 或中间件做了 SQL 重写（比如自动加 limit offset），可能把
NULLS LAST吃掉 - 真正跨库安全的写法仍是
name IS NULL, name ASC—— 它本质是把空/非空拆成两层逻辑，不依赖方言扩展
组合索引能否加速这种排序？关键看字段顺序是否严格对齐
带 IS NULL 或 CASE WHEN 的排序无法走普通 B-tree 索引，但纯字段顺序排序（如 ORDER BY name, code, create_time）可以。前提是索引字段顺序、方向、以及 WHERE 条件中的过滤字段，三者必须和 ORDER BY 完全一致。
- 查询写成
WHERE status = 'active' ORDER BY name ASC, code ASC，理想索引是(status, name, code)；若建了(name, code, status)，基本无效 - MySQL 5.7 要求索引方向也完全匹配：
ORDER BY name ASC, code DESC需要索引声明为(name ASC, code DESC)；8.0+ 才支持反向扫描 - 低区分度字段（如
is_deleted TINYINT）别放索引左边——它会让后续字段的索引筛选失效，相当于全表排序
reviewer_id = 0 和 reviewer_id IS NULL，前者可能是合法的“无审核人”标记，后者才是缺失数据。排序时混用 IS NULL 和 = 0，结果可能完全偏离预期。 
