MongoDB 8.0 从零入门 - 会说资源网

什么是MongoDB？与MySQL的核心区别及应用场景解析

当我们作为开发者或者产品经理在构思一个新项目时，数据层的选型往往决定了后续开发的灵活性。在很长一段时间里，关系型数据库（如MySQL）是默认选项，但随着移动互联网、物联网以及AI应用的爆发，数据形态变得越来越复杂且多变。MongoDB 正是为了解决这种“数据结构不确定”和“快速迭代”的痛点而诞生的。

MongoDB 是一个基于分布式文件存储的文档型数据库（Document Database），由 MongoDB Inc. 开发和维护。与 MySQL 按行和列存储数据不同，MongoDB 使用 BSON（Binary JSON）格式存储数据。这意味着你可以直接将一个包含嵌套对象、数组的完整数据结构存入一条记录中，而不需要像 MySQL 那样先进行复杂的表结构设计（Schema 设计）。

核心差异：MongoDB vs MySQL

为了更直观地理解两者的区别，我们可以从以下几个维度进行对比：

| 维度 | MySQL (关系型) | MongoDB (文档型) |

| :--- | :--- | :--- |

| 数据模型 | 二维表结构，严格的行列定义 | JSON/BSON 文档，数据结构灵活，支持嵌套 |

| Schema 灵活性 | 强约束，修改表结构通常需要 ALTER TABLE，成本高 | 无模式 (Schema-less)，同一集合中的文档结构可以不同 |

| 扩展性 | 垂直扩展为主，水平分库分表复杂 | 原生水平扩展 (Sharding)，数据自动分布在多台机器 |

| 事务支持 | 原生支持完整的 ACID | 支持多文档 ACID 事务，兼顾灵活性与一致性 |

| 查询语言 | SQL (结构化查询语言) | MongoDB Query Language (基于文档的查询) |

| 适用场景 | 财务系统、ERP 等结构化数据场景 | 内容管理、实时分析、AI 应用、IoT |

为什么选择 MongoDB？场景解析

1. 快速迭代的互联网产品

在产品的早期阶段，需求变化频繁。如果你使用 MySQL，每次新增一个字段可能都需要修改数据库表结构，甚至影响线上服务。而在 MongoDB 中，你可以直接写入新的字段。例如，用户画像数据可能包含基础信息，也可能包含动态增加的标签，MongoDB 的文档模型天然契合这种需求。

2. 实时分析与日志处理

MongoDB 非常适合存储用户行为日志或应用日志。其内置的聚合框架（Aggregation Framework）可以对海量数据进行实时处理，而无需将数据导出到复杂的 Hadoop 生态中。

3. AI 应用与向量搜索

这是 MongoDB 8.0（于2024年10月正式发布）重点强化的能力。随着生成式 AI 的兴起，RAG（检索增强生成）应用需要存储大量的 Embedding 向量。MongoDB 8.0 增强了向量搜索（Vector Search）能力，允许你直接在数据库中存储向量并进行近似最近邻搜索（ANN），使其成为 AI 应用的核心记忆单元。

4. 物联网（IoT）与时序数据

对于海量设备上报的传感器数据，MongoDB 提供了时序集合（Time Series Collections），针对时间序列数据进行了写入和存储优化，能够显著降低存储成本。

开发者社区的热门讨论

在 2024-2026 年的技术趋势中，开发者经常讨论的一个话题是：MongoDB 能否替代 Elasticsearch？

随着 MongoDB 在全文搜索和向量搜索能力上的增强，很多团队开始尝试用 MongoDB Atlas Search 来统一搜索和数据库层，减少技术栈的复杂度。此外，Schema Design Anti-patterns（如避免过度嵌套数组）也是社区中高频讨论的话题，因为良好的设计是发挥 MongoDB 性能的关键。

---

MongoDB 8.0 环境搭建与 Atlas 云数据库快速上手

作为全栈工程师，我们不仅要关注代码，还要关注部署效率。在本地开发环境搭建 MongoDB 固然重要，但在云原生时代，直接使用 MongoDB Atlas 往往是更高效的选择。MongoDB 8.0 于 2024年10月发布，带来了存储引擎的优化和 bulkWrite 的性能改进，降低了大规模部署的硬件成本。

本地环境搭建 (Docker 方式)

为了快速启动一个纯净的 MongoDB 8.0 实例，我推荐使用 Docker。这种方式避免了在操作系统上直接安装软件带来的环境污染。

执行以下命令启动一个 MongoDB 8.0 容器：

docker run --name mongo-8 \
  -p 27017:27017 \
  -d \
  --restart always \
  -e MONGO_INITDB_ROOT_USERNAME=admin \
  -e MONGO_INITDB_ROOT_PASSWORD=password123 \
  mongodb/mongodb-community-server:8.0

参数解释：

-p 27017:27017：将容器的 27017 端口映射到主机。
-e MONGO_INITDB_ROOT_USERNAME：设置管理员用户名。
mongodb/mongodb-community-server:8.0：指定拉取 8.0 版本的镜像。

容器启动后，你可以使用 MongoDB Shell (mongosh) 连接：

mongosh "mongodb://admin:password123@localhost:27017"

云端快速上手：MongoDB Atlas

如果你不想维护服务器，或者需要测试 向量搜索 和 全球集群 功能，MongoDB Atlas 是全托管的 DBaaS 服务，也是官方推荐的生产级解决方案。

Atlas 注册与集群创建流程：

访问 MongoDB Atlas 官网并注册账号。
点击 "Create a Cluster"。
选择云服务商（AWS, Azure 或 GCP）以及区域。
在版本选择中，确保选中 MongoDB 8.0。
对于开发测试，可以选择 M0 Sandbox (免费层级)，它足以支撑初期学习。

创建完成后，你需要配置 Network Access（允许你的 IP 地址访问）和 Database Access（创建数据库用户）。

连接字符串与驱动配置

Atlas 创建完成后，会提供一个标准的连接字符串（Connection String）。这个字符串是应用程序连接数据库的钥匙。

例如，一个典型的 Node.js 连接示例：

const { MongoClient } = require('mongodb');

// Atlas 提供的连接字符串
const uri = "mongodb+srv://<username>:<password>@cluster0.mongodb.net/?retryWrites=true&w=majority";

const client = new MongoClient(uri);

async function run() {
  try {
    await client.connect();
    // 连接成功，返回管理员信息
    const adminDb = client.db().admin();
    const result = await adminDb.serverStatus();
    console.log("MongoDB Version:", result.version); // 应输出 8.0 或对应版本
    console.log("Connection successful!");
  } finally {
    await client.close();
  }
}

run().catch(console.dir);

未来趋势：Serverless 与多云

在 Atlas 中，你还可以尝试 Serverless Instances。根据 2024-2026 年的技术趋势，MongoDB 正在优化无服务器实例的冷启动和自动伸缩能力。对于流量波动极大的应用（如活动页、短期促销），Serverless 模式可以让你按实际使用的读写次数计费，而不是预置容量。

此外，如果你关注开发者数据平台的演进，Atlas 现在还支持与 Data Lake 的联邦查询（Federated Query），这意味着你可以直接通过 MongoDB 的查询语法去查询存储在对象存储（如 AWS S3）中的历史数据，实现了 operational data（运营数据）与 historical data（历史数据）的无缝结合。

---

CRUD 操作实战：使用 BSON 文档模型与 Compass 可视化管理

了解了 MongoDB 的优势并搭建好环境后，接下来我们进入实战环节。CRUD（Create, Read, Update, Delete）是所有数据库操作的基础。MongoDB 的核心在于其文档模型，理解这一点对于从 MySQL 转过来的开发者至关重要。

文档模型：BSON 的灵活性

在 MongoDB 中，一条记录就是一个文档（Document），类似于 JSON 对象。但它实际上是 BSON，支持更多的数据类型（如 Date, ObjectId, Binary Data）。

例如，一个电商场景下的“订单”文档可能长这样：

{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "orderId": "ORD-2024-001",
  "user": {
    "name": "张三",
    "email": "zhangsan@example.com"
  },
  "items": [
    { "product": "Laptop", "qty": 1, "price": 1200 },
    { "product": "Mouse", "qty": 2, "price": 25 }
  ],
  "total": 1250,
  "createdAt": ISODate("2024-10-27T10:00:00Z")
}

注意这里的结构：它包含了嵌套对象（user）和数组（items），这在 MySQL 中通常需要拆分成三张表（Orders, Users, OrderItems），而在 MongoDB 中，一次查询即可获取完整数据。

使用 MongoDB Shell 进行 CRUD

假设我们已经连接到了数据库 shop，并操作其中的 products 集合。

1. Create (插入)

使用 insertOne 或 insertMany。

// 切换到 shop 数据库
use shop

// 插入单个文档
db.products.insertOne({
    name: "iPhone 16 Pro",
    brand: "Apple",
    price: 8999,
    specs: { screen: "6.1 inch", chip: "A18" },
    tags: ["phone", "new"]
})

// 插入多个文档
db.products.insertMany([
    { name: "Galaxy S25", brand: "Samsung", price: 7999, tags: ["phone", "android"] },
    { name: "MacBook Air", brand: "Apple", price: 9999, tags: ["laptop"] }
])

2. Read (查询)

MongoDB 的查询语句非常直观，使用 JSON 格式作为查询条件。

// 查询所有 Apple 品牌的产品
db.products.find({ brand: "Apple" })

// 查询价格大于 8000 的产品
db.products.find({ price: { $gt: 8000 } })

// 只返回 name 和 price 字段 (投影)
db.products.find({ brand: "Apple" }, { name: 1, price: 1, _id: 0 })

3. Update (更新)

更新操作包含更新运算符，如 $set（设置值）、$inc（自增）。

// 将 iPhone 16 Pro 的价格降低 500
db.products.updateOne(
    { name: "iPhone 16 Pro" },
    { $set: { price: 8499 } }
)

// 给所有 Apple 产品打上 "promotion" 标签
db.products.updateMany(
    { brand: "Apple" },
    { $push: { tags: "promotion" } }
)

4. Delete (删除)

// 删除名为 MacBook Air 的文档
db.products.deleteOne({ name: "MacBook Air" })

可视化管理：MongoDB Compass

虽然 Shell 很强大，但对于数据结构的可视化分析，MongoDB Compass 是官方提供的利器。它无需你写代码就能浏览数据、创建索引和优化查询。

使用 Compass 的步骤：

下载并安装 MongoDB Compass。
输入连接字符串（如 mongodb://admin:password123@localhost:27017）。
连接后，你可以看到左侧的数据库列表。
点击 shop -> products，你可以看到刚才插入的数据以结构化的方式展示。
Schema 分析：Compass 有一个非常实用的功能叫 "Analyze Schema"。它会扫描集合中的文档，统计字段的分布情况。例如，它会告诉你 brand 字段有 50% 是 "Apple"，30% 是 "Samsung"。这对于理解非结构化数据的特征非常有帮助。

面试高频点：索引与慢查询

在实际开发中，随着数据量增长，查询会变慢。MongoDB 的索引机制与 MySQL 类似。

// 在 brand 字段上创建索引
db.products.createIndex({ brand: 1 })

// 使用 explain 查看查询计划
db.products.find({ brand: "Apple" }).explain("executionStats")

在面试中，经常会被问到“如何排查慢查询”。答案通常是查看 system.profile 集合，或者使用 explain() 方法分析查询是否命中了索引（看 winningPlan.inputStage.stage 是否为 IXSCAN）。

---

进阶核心：聚合管道(Aggregation)与多文档 ACID 事务

当你不再满足于简单的增删改查，而是需要对数据进行复杂的统计分析，或者需要保证一组操作的原子性时，就需要掌握 MongoDB 的聚合管道和事务了。这是 MongoDB 从单纯的“存储”走向“数据处理平台”的关键能力。

聚合管道 (Aggregation Pipeline)

聚合管道是 MongoDB 中用于数据处理的强大框架。你可以将其想象成流水线，数据经过一个个“阶段”（Stage）的处理，最终输出结果。每个阶段接收输入文档，对其进行处理，然后将输出传递给下一个阶段。

核心阶段包括：

$match：过滤文档（类似 find）。
$group：按字段分组并进行累加计算（类似 SQL 的 GROUP BY）。
$project：重塑文档结构（选择、增加或删除字段）。
$sort：排序。
$limit：限制返回数量。

实战案例：分析电商订单数据

假设我们有一个 orders 集合，包含大量订单。我们需要计算每个用户的订单总金额，并只显示总金额大于 1000 的用户。

db.orders.aggregate([
    // 阶段 1: 过滤有效订单
    {
        $match: {
            status: "completed"
        }
    },
    // 阶段 2: 按 userId 分组，计算总金额
    {
        $group: {
            _id: "$userId", // 分组依据
            totalSpent: { $sum: "$totalAmount" }, // 累加总金额
            orderCount: { $sum: 1 } // 计数
        }
    },
    // 阶段 3: 过滤掉总金额小于 1000 的组
    {
        $match: {
            totalSpent: { $gt: 1000 }
        }
    },
    // 阶段 4: 排序
    {
        $sort: {
            totalSpent: -1
        }
    }
])

这段代码展示了聚合管道的强大之处：它可以在数据库层面完成复杂的 ETL（抽取、转换、加载）操作，而不需要把海量数据拉到应用程序内存中处理。

多文档 ACID 事务

虽然 MongoDB 早期的版本以高性能和非关系型著称，但 MongoDB 4.0 引入了多文档事务，并在后续版本中不断优化。到了 MongoDB 8.0，事务的性能已经非常成熟。

什么时候需要事务？

当你需要执行一系列操作，且这些操作要么全部成功，要么全部失败时。例如，在金融系统中，从 A 账户扣款和给 B 账户加款必须是一个原子操作。

事务代码示例 (Node.js Driver)：

const { MongoClient } = require('mongodb');

const uri = "mongodb://admin:password123@localhost:27017";
const client = new MongoClient(uri);

async function transferFunds(fromUserId, toUserId, amount) {
    const session = client.startSession();

    try {
        await session.withTransaction(async () => {
            const accounts = client.db('bank').collection('accounts');

            // 1. 从转出账户扣款
            const fromUpdate = await accounts.updateOne(
                { userId: fromUserId, balance: { $gte: amount } }, // 条件：余额足够
                { $inc: { balance: -amount } },
                { session } // 关键：传入 session
            );

            if (fromUpdate.matchedCount === 0) {
                throw new Error("余额不足或账户不存在");
            }

            // 2. 给转入账户加款
            await accounts.updateOne(
                { userId: toUserId },
                { $inc: { balance: amount } },
                { session }
            );

            console.log("转账成功！");
        });
    } catch (error) {
        console.error("转账失败，已回滚:", error.message);
    } finally {
        await session.endSession();
    }
}

// 执行函数
async function main() {
    await client.connect();
    await transferFunds("user_A", "user_B", 500);
    await client.close();
}

main();

技术趋势与面试要点

1. 向量搜索与 AI 集成

在 MongoDB 8.0 中，聚合管道已经集成了向量搜索能力。这意味着你可以在一个查询中同时进行全文搜索和向量相似度搜索。例如，在构建 RAG 应用时，你可以先通过 $vectorSearch 找到最相关的文档片段，再通过 $lookup 关联其他元数据。

2. 面试高频问题解析

在面试中，关于事务的问题通常是：“MongoDB 是否支持事务？有什么限制？”

答案是：支持。但需要注意的是，虽然 MongoDB 支持多文档事务，但不建议在高频写入场景下长时间持有事务，因为事务会占用连接资源并可能导致锁竞争。对于大多数不需要跨文档原子性的场景，利用文档模型的嵌套特性（将相关数据存在一个文档里）是更好的选择，这被称为“设计模式”优于“强制事务”。

3. 性能优化

MongoDB 8.0 对 bulkWrite 进行了改进。如果你需要批量写入大量数据，使用事务包裹 bulkWrite 可以显著提升性能，因为减少了网络往返次数。这在数据迁移或初始化大批量数据时非常有用。

5. 高可用与AI集成：复制集原理、水平扩展及原生向量搜索(Vector Search)

聊到生产环境，单节点跑 MongoDB 就是裸奔。MongoDB 8.0 里最核心的生存技能就是复制集（Replica Set）。它本质上是一组维护相同数据集的 mongod 进程。你可能会问，不就是主从复制吗？其实差别挺大。复制集里有个选举机制，当 Primary 节点挂了，剩下的 Secondary 节点会立马开会，投票选出一个新的老大，整个过程应用层几乎无感知。这种自动故障转移（Automatic Failover）才是高可用的真谛。

在 8.0 版本里，复制集的配置依旧简单粗暴。假设我们在本地模拟三个节点，端口分别是 27017, 27018, 27019。初始化复制集的姿势是这样的：

// 连接到任意一个节点，比如 27017
mongosh --port 27017

// 初始化配置
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "localhost:27017" },
    { _id: 1, host: "localhost:27018" },
    { _id: 2, host: "localhost:27019" }
  ]
})

// 查看状态
rs.status()

当数据量突破单机的物理极限，或者写操作太频繁，就得上分片（Sharding）了。分片就是把数据水平拆开，存在不同的机器上。MongoDB 的分片集群包含三个角色：Shard（存数据）、Config Server（存元数据）、Mongos（路由）。虽然搭建起来比复制集麻烦不少，但对于海量数据来说，这是唯一的出路。

除了传统的 CRUD，现在做后端如果不提 AI，感觉都不好意思打招呼。MongoDB 8.0 在 Vector Search 上发力很猛。以前我们要做向量检索，得额外维护一个 Milvus 或者 Pinecone，现在直接在 MongoDB 里就能搞定。它原生支持存储高维向量（Embedding），并且能建立向量索引。

比如我们要做一个简单的 RAG（检索增强生成）应用，需要存储一些文档片段和对应的向量。代码逻辑大概是这样的：

// 假设我们使用 Node.js Driver
const { MongoClient } = require('mongodb');

async function run() {
  const client = new MongoClient('mongodb://localhost:27017');
  await client.connect();
  const database = client.db('ai_demo');
  const collection = database.collection('documents');

  // 1. 插入带有向量的文档
  await collection.insertMany([
    {
      text: "MongoDB 8.0 引入了更高效的批量写入机制",
      embedding: [0.12, 0.34, 0.56, 0.78, 0.90, 0.11, 0.22, 0.33] // 假设这是 8 维向量
    },
    {
      text: "复制集提供了自动故障转移能力",
      embedding: [0.45, 0.67, 0.89, 0.12, 0.34, 0.56, 0.78, 0.90]
    }
  ]);

  // 2. 创建向量索引 (Atlas 环境下或本地支持向量索引的版本)
  // 注意：向量索引的创建语法依赖具体环境，这里展示 Atlas Vector Search 索引定义逻辑
  // 实际在 Atlas 控制台配置 JSON 如下：
  // {
  //   "fields": [
  //     {
  //       "type": "vector",
  //       "path": "embedding",
  //       "numDimensions": 8,
  //       "similarity": "cosine"
  //     }
  //   ]
  // }

  // 3. 执行向量搜索 (使用 $vectorSearch 聚合阶段)
  const aggResult = await collection.aggregate([
    {
      $vectorSearch: {
        index: "vector_index",
        path: "embedding",
        queryVector: [0.10, 0.30, 0.50, 0.70, 0.90, 0.10, 0.30, 0.50],
        numCandidates: 10,
        limit: 2
      }
    }
  ]).toArray();

  console.log("相似文档:", aggResult);
  await client.close();
}

run().catch(console.dir);

这种原生集成意味着你的技术栈可以更收敛。特别是 MongoDB Atlas 提供的 vCore 架构下的 Vector Search，让性能和定价模型更加透明。对于需要结合上下文记忆的 AI 应用，直接把对话历史和 Embedding 存在同一个文档里，查询的时候利用聚合管道一次性把向量相似度和业务过滤都做了，非常顺滑。

水平扩展的痛点

分片虽然能解决存储问题，但热点块（Hot Chunks）是个让人头疼的事。如果分片键选得不好，比如用了自增 ID，所有新数据都会往最后一个分片写，导致那个分片 IO 爆表。所以选分片键（Shard Key）是个技术活，得选基数大、随机性高且不会被频繁更新的字段。

6. 性能优化与避坑指南：索引策略与 Schema 设计反模式

很多开发者刚从 MySQL 转过来，容易把 MongoDB 当成关系型数据库用，结果就是性能稀烂。在 MongoDB 8.0 里，索引依然是性能的生命线。没有索引的查询就是全集合扫描（Collection Scan），数据量一大，CPU 直接拉满。

MongoDB 支持多种索引，最常用的是单字段索引和复合索引。这里有个细节，复合索引的字段顺序是有讲究的，得遵循 ESR 原则（Equality, Sort, Range）。也就是把精确匹配的字段放最前，排序字段放中间，范围查询字段放最后。

比如我们要查询年龄等于 30 岁，按注册时间倒序，且积分大于 100 的用户：

// 创建复合索引
db.users.createIndex({ age: 1, regDate: -1, points: 1 })

// 查询语句
db.users.find({ 
  age: 30, 
  points: { $gt: 100 } 
}).sort({ regDate: -1 })

这个索引就能被完美利用。排查慢查询的时候，别瞎猜，直接用 explain() 看执行计划。

// 查看查询的执行计划
db.users.find({ email: "test@example.com" }).explain("executionStats")

如果看到 winningPlan.stage 是 COLLSCAN，那就得赶紧加索引了。如果是 IXSCAN，还得看看 totalDocsExamined 是不是远大于 nReturned，如果是，说明索引没建好，有回表查询的开销。

Schema 设计的反模式

聊完索引，得说说 Schema 设计。MongoDB 虽然灵活，但不代表你可以乱存。社区里讨论最多的反模式就是过度嵌套（Massive Arrays）。

比如有个电商系统，你在 User 文档里直接嵌套了 Orders 数组。听起来很合理，对吧？但用户下单多了，这个数组会无限膨胀。MongoDB 单个文档有 16MB 的限制，而且更新大文档的代价很高。这就是典型的反模式：无限增长的数组。

正确的做法应该是把订单单独拆成一个集合（Collection），通过 userId 关联。

另外一个坑是索引滥用。有些同学为了查询快，给所有字段都加索引。这会导致写入性能急剧下降，因为每次写入都要更新一堆索引树。特别是 8.0 版本对 bulkWrite 做了优化，如果你索引太多，批量写入的优势就被索引维护的消耗给抵消了。

还有一个最近社区吵得挺凶的话题：MongoDB 能不能替代 Elasticsearch？

如果你只是做简单的全文搜索或者向量搜索，MongoDB 8.0 的原生能力确实够用了，省去了维护 ES 集群的麻烦。但如果你需要极其复杂的分词、相关性评分调优，ES 还是更专业。不过对于大多数中小项目，为了搜索专门搞个 ES 集群，运维成本太高，MongoDB 的一站式解决方案其实更香。

异步驱动的最佳实践

现在 Node.js 和 Java 的驱动都强调异步非阻塞。写代码的时候千万别把异步操作写成同步阻塞的。比如在循环里 await 数据库操作，这是性能杀手。尽量利用批量操作（Bulk Operations）或者聚合管道（Aggregation Pipeline）在服务端一次性处理完数据，减少网络往返。

7. 总结：MongoDB 在 2024-2026 年的技术趋势与面试要点

回头看 MongoDB 8.0 的发布（2024年10月），你会发现它不再只是一个简单的文档数据库，而是在往开发者数据平台的方向狂奔。未来两三年，有几个趋势是躲不掉的。

AI 原生化是重头戏。随着生成式 AI 的爆发，MongoDB 作为 AI 应用的核心记忆单元 地位会越来越稳。原生向量搜索、与 LangChain 等框架的深度集成，会让它成为 RAG 架构的首选存储。特别是 Atlas 上关于 vCore 和 Serverless 的优化，会让开发者在成本和性能之间找到更好的平衡。

多云和 Serverless 也是大方向。谁也不想天天盯着数据库扩容。MongoDB Atlas 的无服务器实例（Serverless Instances）在冷启动和自动伸缩上还会继续迭代，以后可能真的就是按请求量付费，连容量规划都不用做了。

存储引擎的优化也会持续。8.0 版本引入的 bulkWrite 改进只是个开始，后续肯定会有更多针对大规模部署的硬件成本优化。毕竟现在云资源挺贵的，能把存储和查询效率提升一点，省下来的都是真金白银。

面试高频考点复盘

如果你最近在准备面试，这几个点基本必问，而且得结合 8.0 的特性来答：

MongoDB 与 MySQL 的核心区别：别只说一个关系型一个非关系型。要提到 BSON 的灵活性、嵌套结构减少 Join、复制集的高可用机制，以及 Sharding 的水平扩展能力。
复制集的自动故障转移：要能讲清楚 心跳检测（Heartbeat）、选举算法（Raft 变种） 以及 Rollback 机制。面试官可能追问如果网络分区会发生什么。
索引与慢查询：不仅要会建索引，还要会用 explain()。特别是 复合索引的 ESR 规则，以及为什么要在 MongoDB 里慎用 $lookup（虽然 8.0 优化了，但大表 Join 依然伤）。
事务支持：MongoDB 从 4.0 开始支持多文档 ACID 事务，8.0 自然也支持。但要清楚它的限制，比如事务默认有时长限制，长时间事务会占用连接资源，不适合长事务场景。

最后，关于 Schema Design Anti-patterns，面试时举几个例子，比如“过度嵌套数组”或者“避免把大二进制文件直接塞进文档（应该用 GridFS）”，能显得你不仅有理论，还有实战经验。MongoDB 的生态现在非常成熟，从驱动到 Atlas 云服务，再到数据湖集成，掌握它绝对是后端工程师的加分项。