MongoDB 查询优化指南四句真言（查询优化系列 4）

AustinDatabases

发布于 2026-03-12 21:25:57

文章被收录于专栏：AustinDatabasesAustinDatabases

MySQL SQL 优化指南 SQL 四句真言（优化系列 3）

SQL SERVER SQL 优化指南四句真言（SQL 优化系列 2）

PostgreSQL SQL 优化指南四句真言（SQL 优化系列 1）

这是SQL优化的第四期了，这回终于转到了MongoDB。或者这个题目不对，MongoDB没有SQL，有的是自己的查询语句体系NoSQL。但大差不差，其实和传统数据库也有类似的地方。今天就说说MongoDB的SQL优化的四句真言。

文档设计很重要，NOSQL优化放后面，

索引类型比较多，遵守ESR的原则，

数据写入与更新，可以同步也异步，

聚合操作要注意，提前过滤再聚合。

MongoDB的数据库查询优化，与传统的数据库有很大的不同，举一个例子，传统数据库是先把饭做出来，在调味，而mongodb的优化应该是先把味道调整好了，在做饭。

所以这就导致一个大的问题，一般DBA没法管好MongoDB,或者没有那个思维的模式来管理，还是按照传统数据库的方式去优化，我们来挨个句子解释。

第一句是模式很重要，这里的模式就是告诉你，建集合（表）的时候非常重要，因为他是无结构化的模式，如果没有设计的规则，查询语句的撰写就更天马行空了，所以模式的选择很重要。

一对多，多对一，多对多，等设计模式在之前很多文章里面写过，同时这还与模式设计里面的嵌套，平铺，数组，等等有关。嵌套的层数不宜过多，3层就差不多了，数组可以使用，但查询中，如果调用数组里面的数据频繁，则不宜将数组里面的元素设计的太多。因为模式设计错误，就会导致查询语句的复杂性和优化的难度的提高，这也是MongoDB 高级技术工程师提出的如何使用MongoDB的分享中提到的，高速的运行查询与良好的设计是分不开的。

那么ESR原则是什么，这个MySQL的DBA肯能知道后，会温故而知新，与MySQL建立索引的原则有异曲同工之妙。ESR是什么。

👉 E (Equality) — 等值

👉 S (Sort) — 排序

👉 R (Range) — 范围

我们举一个例子，来说明这个原则

db.orders.insertMany([
  { order_id: 1, user_id: 101, status: "PAID", order_date: ISODate("2025-08-01"), total: 500 },
  { order_id: 2, user_id: 102, status: "PENDING", order_date: ISODate("2025-08-02"), total: 200 },
  { order_id: 3, user_id: 101, status: "PAID", order_date: ISODate("2025-08-05"), total: 1000 },
  { order_id: 4, user_id: 103, status: "CANCELLED", order_date: ISODate("2025-08-08"), total: 50 }
]);

db.orders.find(
  { user_id: 101, status: "PAID", total: { $gte: 500 } }
).sort({ order_date: -1 });

db.orders.createIndex(
  { user_id: 1, status: 1, order_date: -1, total: 1 }
);

一句话解释，建立索引的字段顺序是，先等值，然后把需要排序的字段放入，最后才是范围的查询字段。按照这个顺序建立的联合索引才是最优的。

第二句，索引类型较多的问题，这里简单列一下MongoDB的索引类型单键索引、复合索引、稀疏索引、部分索引、TTL 索引、全文索引、地理空间索引、哈希索引等等。

这里解释一下传统数据库中没有的索引类型

1 部分索引，部分索引可不是传统DBA理解的，一个字段取其中的字段值的模糊索引，NO NO NO。这个部分索引是，查询字段查那个给那个字段的值建立索引。传统DBA 估计把脑袋撞破也不理解。举个例子吧: 我们有一个

{
  _id: ObjectId(),
  order_id: Number,
  user_id: Number,
  amount: Number,
  status: String,   // 可能的取值：CREATED, PAID, CANCELLED, REFUNDED
  created_at: Date
}

这里我们查询中的条件只有PAID


db.orders.find({ status: "PAID" })

那么我们的部分索引就建立成

db.orders.createIndex(
  { status: 1 },
  { partialFilterExpression: { status: "PAID" } }
)

db.orders.find({ status: "PAID" }).explain("executionStats")

"winningPlan": {
   "stage": "IXSCAN",
   "indexName": "status_1_partial"
}

这在传统数据库是无法实现，不能想象的，那为什么MongoDB可以这样做，原因就在于节省有效的索引空间，只记录 PAID的字段的物理位置，不查询的那些字段都不记录，最大化的通过自由的手段来优化查询，速度一定是非常快，但前提是你的理解业务。

第二个是传统DBA不曾见过的稀疏索引，稀疏索引（Sparse Index）只为存在某字段的文档建立索引。没有该字段的文档不会进入索引

我们还是举一个例子

db.orders.insertMany([
  { order_id: 1, user_id: 101, amount: 500, status: "PAID" },
  { order_id: 2, user_id: 102, amount: 200 },                 // 无 status
  { order_id: 3, user_id: 103, amount: 300, status: "PAID" },
  { order_id: 4, user_id: 104, amount: 150 }                  // 无 status
]);

db.orders.createIndex({ status: 1 }, { sparse: true });

db.orders.find({ status: "PAID" });

这里我们注意稀疏索引的特点是如果document有的有status ,有的没有则只对有status的key进行建立索引。

关于SQL优化的部分，在insert ,delete ,update等操作中如果了解业务，可以在语句中添加同步或异步的语句。在操作大量的DML语句时，在MongoDB中是可以选择数据写入的方式的，下面有几种方式案例

1 数据写入并不马上查询，但有大量的数据要写入。

db.orders.insertOne(
  { order_id: 2, user_id: 102, amount: 200, status: "CREATED" },
  { writeConcern: 0 }   // 异步写入
);

2 数据插入后，马上就要查询到，（主库插入，其他节点查询）

db.orders.updateOne(
  { order_id: 1 },
  { $set: { status: "PAID" } },
  { writeConcern: { w: "majority", j: true } }  // 等待磁盘和多数节点确认
);

以此类推，任何的操作都可以通过writeConcern 的设置来满足不同业务对于数据库DML的处理需求。

最后一句是关于聚合操作的部分，聚合操作一直是MongoDB的一个需要解决的问题，常见我们的方案是提前过滤需要过滤的数据。

下面把两种语句的写法拿出来，一个错误的，一个正确的

错误的

db.orders.aggregate([
  { $group: { _id: "$customer_id", total: { $sum: "$amount" } } },
  { $match: { total: { $gt: 1000 } } }  // 后过滤，浪费计算
]);

正确的

db.orders.aggregate([
  { $match: { status: "PAID" } },  // 先过滤
  { $group: { _id: "$customer_id", total: { $sum: "$amount" } } },
  { $match: { total: { $gt: 1000 } } }  // 再过滤聚合结果
]);

正确的写法，是将过滤数据写到前面同时减少project映射的字段，减少无效的数据传输。

对于嵌套数据的优化也有两种写法一种错误，一种正确。

db.orders.insertMany([
  { order_id: 1, customer_id: 101, items: [{ sku: "A1", qty: 2 }, { sku: "B2", qty: 1 }] },
  { order_id: 2, customer_id: 102, items: [{ sku: "A1", qty: 1 }, { sku: "C3", qty: 5 }] }
]);

错误写法
db.orders.aggregate([
  { $unwind: "$items" },                 // 先拆全部数组
  { $match: { "items.sku": "A1" } },    // 再过滤
  { $group: { _id: "$items.sku", total_qty: { $sum: "$items.qty" } } }
]);

正确写法

db.orders.aggregate([
  { $project: { customer_id: 1, items: { $filter: { input: "$items", as: "item", cond: { $eq: ["$$item.sku", "A1"] } } } } },
  { $unwind: "$items" },                 // 只拆符合条件的数组元素
  { $group: { _id: "$items.sku", total_qty: { $sum: "$items.qty" } } }
]);

这里如果有时间类型聚合的大量需求，要在MongoDB中完成，也可以更新到MongoDB 8.0,针对于时间聚合方面，在不改变任何语句的情况下，复杂的时间序列聚合操作速度提升明显，通过block processing 的机制，提高了时间聚合操作的性能。同时对于_id object_id的直接查询，引入了expresspath的查询模式，不再通过查询计划，而是直接访问存储引擎，速度更快。

每种数据库有每种的优化的方法和特性，抓住核心，在增加需要优化的数据库本身的特性，就可以快速扩展，添加新的技能。

置顶

MySQL SQL 优化指南 SQL 四句真言（优化系列 3）

沧海要，《SQL SERVER 运维之道》，清风笑，竟惹寂寥

SQL SERVER SQL 优化指南四句真言（SQL 优化系列 2）

PostgreSQL SQL 优化指南四句真言（SQL 优化系列 1）

从 Universal 环球影城到国产数据库产品营销 --驴唇对马嘴

3种方式 PG大版本升级接锅，背锅，不甩锅以客户为中心做产品

"PostgreSQL" 不重启机器就能调整 shared buffer pool 的原理

超强外挂让MySQL再次兴盛，国内神秘组织拯救MySQL行动

AI 很聪明，但就怕脑子失忆，记忆对AI很重要

从某数据库信任“危机”，简谈危机公关