ORDER BY多字段按从左到右顺序决定优先级，先按首字段排序，相同时再按次字段排序，各字段可独立指定ASC/DESC，NULL默认排首或尾，需用COALESCE或NULLS FIRST/LAST统一处理，索引利用要求字段顺序和方向严格匹配。
ORDER BY 多字段怎么写才按预期优先级排序
SQL 的 ORDER BY 后面跟多个字段时，顺序就是优先级：越靠前的字段权重越高。比如 ORDER BY status, created_at DESC，先按 status 升序排，相同 status 的再按 created_at 降序排——不是“同时比较”，而是分层排序。
常见错误是以为写成 ORDER BY a, b 就能“综合打分”，结果发现 a 值差异大时，b 根本没机会影响整体顺序。这恰恰是对的，不是 bug。
- 每个字段可独立指定
ASC或DESC，不写默认ASC - 混合方向时，别省略显式声明，比如
ORDER BY priority DESC, updated_at ASC - NULL 值默认排在最前（
ASC）或最后（DESC），不同数据库行为略有差异，MySQL 和 PostgreSQL 一致，但 SQLite 可能不同
NULL 值干扰排序时怎么统一处理
多列排序中，只要某列含 NULL，就容易让结果看起来“乱序”——其实它严格按规则排了，只是 NULL 的位置不符合直觉。
例如 ORDER BY category, score DESC，category 为 NULL 的行会扎堆排在最前面（ASC 规则），哪怕它们的 score 很高。
- 用
COALESCE(category, 'zzz')把NULL映射成可控值（注意类型要一致） - PostgreSQL 支持
NULLS FIRST/NULLS LAST，MySQL 8.0+ 也支持，但老版本只能靠函数兜底 - 避免用
IS NULL在ORDER BY里做条件判断，语法不通用，且无法利用索引
组合排序能走索引吗？关键看字段顺序和方向
能不能用上索引，不取决于你写了几个字段，而取决于是否匹配已建索引的最左前缀 + 方向一致性。
比如有联合索引 INDEX idx_status_created (status, created_at)，那么 ORDER BY status, created_at DESC 在 MySQL 中就无法使用该索引的排序能力（因为方向不一致），会触发 filesort。
- 索引字段顺序必须和
ORDER BY字段顺序完全一致 - 所有字段排序方向需相同（全
ASC或全DESC），MySQL 8.0+ 支持混合方向索引，但得显式创建INDEX(... ASC, ... DESC) -
WHERE条件里的等值字段，可以作为索引前缀，不影响后续排序字段走索引，例如WHERE status = 'active' ORDER BY created_at DESC能用上(status, created_at)索引
需要动态调整排序优先级时别拼 SQL 字符串
后端根据用户选择切换排序字段（比如前端选“按价格低→高”或“按销量高→低”），直接字符串拼接 ORDER BY 是典型 SQL 注入温床。
更安全的做法是预定义合法字段映射表，再用参数化方式构造排序逻辑。
- 用白名单控制字段名：
allowed_sorts = {'price': 'price', 'sales': 'sales_count', 'name': 'product_name'} - 方向只接受
'ASC'或'DESC'字符串，不从请求里直接取 - 不要用 ORM 的 raw query 拼接，Django 可用
.order_by()链式调用，SQLAlchemy 可用sort_by()+text()安全包装
多列排序本身不复杂，难的是在 NULL 处理、索引利用、动态场景下保持行为稳定。最容易被忽略的是：你以为在控制“最终呈现顺序”，实际上数据库只认字段优先级和 NULL 规则，其余全是幻觉。
