数据库里的高级个关ORDER BY子句后面跟了三个字段，排序结果却只认第一个。排序这事我遇到过不止一次。只针第一次是对单段进给电商后台做订单列表，产品经理要求"按金额降序，键字金额相同的行排序按时间降序"。SQL写出来跑了一遍，高级个关金额确实降了，排序但时间那列完全乱掉。只针我盯着结果看了半天，对单段进才发现问题出在排序键的键字优先级上——第二字段根本没参与比较，因为第一字段的行排序值已经把所有行区分开了。

排序算法在处理多字段时，高级个关逻辑是排序逐级比较。拿快速排序来说，只针比较函数先看第一个字段，如果a和b在这个字段上不相等，直接返回结果，后面的字段连碰都不碰。只有当第一字段完全相等时，才会去看第二字段。这意味着一个关键事实：如果第一字段的基数足够大，后续字段在排序中几乎不起作用。

举个具体的例子。假设有一张用户表，字段是user_id（自增主键）、city（城市）、age（年龄）。你写ORDER BY user_id, city, age，这跟只写ORDER BY user_id没有任何区别。因为user_id是唯一的，每一行的值都不同，比较函数在第一轮就分出了胜负，city和age永远等不到出场的机会。

什么时候多字段排序才真正生效

第一字段必须有重复值。这是前提条件。比如ORDER BY city, age，如果"北京"有500条记录，"上海"有300条，那么在北京这个分组内部，排序才会按照age来排。上海分组同理。跨分组之间，age不参与比较——北京的25岁不会排到上海的30岁前面，因为city已经决定了分组顺序。

我见过一个典型的误用场景。某数据分析师写了一条查询，想按"部门+绩效+入职时间"三个维度排序，结果发现绩效列在部门内部并没有正确排序。查了半天，原来是绩效字段存的是字符串，"10"排在"9"前面。这跟多字段排序机制无关，但暴露了一个问题：排序字段的数据类型和值分布，比字段数量更值得关注。

索引对排序的干扰

数据库优化器有时候会走索引来避免文件排序。如果存在联合索引(city, age)，那么ORDER BY city, age可以直接利用索引的有序性，不需要额外的排序步骤。但如果你写的是ORDER BY age, city，索引就用不上了，因为索引的物理顺序是city在前。这时候优化器要么做全表扫描加文件排序，要么走索引但需要额外处理。执行计划里出现Using filesort，往往就是这个原因。

MySQL 8.0之后有了降序索引，可以创建(city ASC, age DESC)这样的索引，匹配混合方向的排序需求。但很多人不知道这个特性，仍然在用5.7时代的思路写查询。我自己的习惯是，写完ORDER BY之后一定用EXPLAIN看一眼，确认排序是否走了索引，还是老老实实在内存或磁盘上做filesort。

一个容易被忽略的边界情况

NULL值在排序中的位置。不同数据库处理方式不同。MySQL里NULL被认为是最小值，ASC排序时排在最前面，DESC时排在最后面。PostgreSQL默认NULLS LAST用于ASC，NULLS FIRST用于DESC。Oracle又不一样。当第一字段存在NULL时，第二字段的排序行为会变得很微妙——所有第一字段为NULL的行会被归为一组，然后在这组内部按第二字段排序。如果你没意识到这一点，结果可能跟预期完全相反。

排序这件事，字段数量从来不是关键。关键在于第一字段的区分度、数据类型的一致性，以及查询计划是否走了索引。把这三个问题搞清楚，比堆砌再多的ORDER BY字段都有用。