ORDER BY 多字段用逗号分隔，优先级从左到右：先按首字段排序，相同时再按次字段排序；可混合ASC/DESC，字段支持列名、别名或表达式；MySQL默认NULL最小，升序排最前；复合索引需顺序与方向匹配才能优化排序。
ORDER BY 后面怎么写多个字段？
直接用逗号分隔字段名，顺序即优先级顺序。第一个字段排完，相同值的记录再按第二个字段排，依此类推。
常见错误是误以为用 AND 或 OR 连接字段，比如写成 ORDER BY name AND age —— 这会报语法错误，因为 AND 是逻辑运算符，不是字段分隔符。
-
ORDER BY status, created_at：先按status升序，status相同时再按created_at升序 -
ORDER BY status DESC, created_at ASC：status降序，同status下created_at升序（ASC可省略） - 字段可以是列名、别名（只要在
SELECT中定义过）、甚至表达式，如ORDER BY LENGTH(name), name
NULL 值在多字段排序里怎么排？
不同数据库对 NULL 的默认排序行为不一致：MySQL 和 PostgreSQL 默认把 NULL 当作最大值（排在最后），SQL Server 默认当最小值（排在最前）。这会导致跨库迁移时排序结果突变。
显式控制更可靠。用 IS NULL 或 IS NOT NULL 配合条件排序：
ORDER BY (status IS NULL) ASC, status, created_at
这段的意思是：先把非 NULL 的 status 放前面，再按 status 和 created_at 排。括号里的布尔表达式返回 0 或 1，ASC 让 0（即非空）优先。
ORDER BY 多字段会影响索引使用吗？
会影响，而且很关键。只有当 ORDER BY 字段顺序与索引字段顺序完全一致，且方向（ASC/DESC）匹配（或全部为 ASC）时，才能用上索引做排序优化。
- 有复合索引
INDEX idx_status_created (status, created_at)→ORDER BY status, created_at可走索引 - 但
ORDER BY created_at, status就无法利用该索引（跳过前导列） -
ORDER BY status DESC, created_at ASC在旧版 MySQL（
为什么加了 ORDER BY 多字段后查询变慢了？
最常见原因是没走索引，触发了文件排序（Using filesort），尤其是数据量大、内存不足时会写临时文件到磁盘。
检查执行计划（EXPLAIN）看 Extra 列是否含 Using filesort。解决路径很直接：
- 确认
ORDER BY字段顺序与现有索引前缀严格匹配 - 避免在排序字段上用函数或表达式，如
ORDER BY UPPER(name)会让索引失效 - 如果必须按计算结果排序，考虑加函数索引（MySQL 8.0+、PostgreSQL 支持）或冗余字段+普通索引
- 注意
SELECT *+ 多字段排序容易让 MySQL 选择全表扫描而非索引覆盖，可尝试只查必要字段
多字段排序本身不复杂，但和索引、NULL 处理、数据库版本绑得太紧，漏掉任一环都可能让结果错位或性能崩掉。
