MongoDB的sort()多字段排序写法为{field1: 1, field2: -1}，其中1表示升序、-1表示降序；字段按从左到右顺序生效，先按首字段排，相同时再按次字段排；方向与字段顺序必须与复合索引严格一致才能走索引加速。
sort() 里多个字段怎么写，1 和 -1 到底代表什么
MongoDB 的 sort() 接收一个文档（object），键是字段名，值是排序方向：1 表示升序（从小到大、A→Z、早→晚），-1 表示降序（从大到小、Z→A、晚→早）。多个字段按书写顺序生效——先按第一个字段排，相同时再按第二个字段排，以此类推。
常见错误是把多个字段写成数组或字符串，比如 sort(["price:1", "name:-1"]) 或 sort("price 1, name -1")，这会直接报错或静默失效。
正确写法示例：
db.orders.find().sort({ "status": 1, "createdAt": -1, "amount": -1 })
含义：先按 status 升序（如 "pending" 在 "done" 前），状态相同时按 createdAt 降序（最新创建的在前），时间也相同时再按 amount 降序。
复合排序时字段顺序错了会怎样
字段顺序不是语法问题，而是逻辑问题。MongoDB 不会警告你“这个顺序不合理”，但结果可能完全不符合预期。
- 如果把
"createdAt": -1放在"status": 1前面，那所有文档会先按时间排，status只在时间完全相同时才起作用——而真实数据中时间极少完全相同，导致status几乎不参与排序 - 对分页场景尤其危险：跳过前 20 条后取下 10 条，如果排序逻辑不稳定（比如主键没包含在 sort 字段里），同一批数据多次查询可能返回不同结果
- 索引匹配依赖字段顺序：如果你建了复合索引
{ status: 1, createdAt: -1 }，那只有sort({ status: 1, createdAt: -1 })能高效使用它；反过来写就走不了索引，变全表扫描
空值、缺失字段和 null 在排序中怎么处理
MongoDB 把 null、缺失字段、undefined 都视为“最小值”，在升序（1）时排最前，在降序（-1）时排最后。这点和 SQL 的 NULLS FIRST/LAST 不同，也没法配置。
实际影响：
- 如果
price字段有些文档没填，sort({ price: 1 })会让这些文档集中在最上面，可能掩盖真正低价商品 - 想让空值靠后？得用聚合管道加
$cond或$ifNull预处理，sort()本身做不到 - 类型不一致也会被当“小值”：比如一个文档
score: null，另一个score: "95"（字符串），MongoDB 会把null排在"95"前面，即使你本意是数值比较
什么时候必须加索引，什么时候加了也白加
复合排序是否走索引，只看两点：字段名是否完全匹配、方向是否一致（或全为 1）。MongoDB 不支持混合方向索引的反向扫描（比如索引是 { a: 1, b: 1 }，但你 sort({ a: 1, b: -1 }) 就无法利用）。
可安全利用索引的组合：
- 索引
{ category: 1, rating: -1, createdAt: -1 }→sort({ category: 1, rating: -1, createdAt: -1 })✅ - 索引
{ user: 1, seq: 1 }→sort({ user: 1 })✅（前缀匹配） - 索引
{ a: 1, b: 1 }→sort({ a: 1, b: 1 })✅，但sort({ a: 1, b: -1 })❌（方向不一致） - 索引
{ a: 1, b: -1 }→sort({ a: -1, b: -1 })❌（首字段方向不匹配）
真正容易被忽略的是：哪怕字段和方向全对上了，如果查询条件（find() 的 filter）没覆盖索引前缀，索引还是用不上。比如索引是 { status: 1, createdAt: -1 }，但你查 find({ createdAt: { $gt: ... } })，没带 status，那这个索引基本无效。
