企业官网建设流程全解析

MongoDB 快速入门这件事，我前后带过不少新人，也帮几个团队做过迁移评估。最深的感受是：这套数据库装起来十分钟，跑通第一条增删改查也用不了一小时，但真正决定后面顺不顺的，是入门阶段脑子里那套模型对不对。很多人拿着关系型数据库的习惯往 MongoDB 里套，表、外键、JOIN 一一对应着搬，跑是能跑，等到数据量上来，查询慢得像蜗牛，回头改模型，成本翻了十倍不止。所以这篇东西不打算写成一份命令手册，而是按我自己带人的顺序，把 MongoDB 快速入门这件事拆成“想清楚—装起来—写进去—查得快—扛得住”几个阶段，每个阶段讲清楚为什么这么做、不这么做会怎样，再配上能直接复制执行的命令和参数。适合完全没有接触过文档型数据库的新手，也适合用过一两次但总觉得哪里别扭、想把底层逻辑理顺的开发者。看完至少能做到：独立部署一个可用实例、设计出一份不会三天后就后悔的集合结构、写出走索引的查询语句，并且知道出问题时该往哪儿看。

1. 入门之前先把定位想明白，别急着敲安装命令

1.1 文档模型到底解决了什么老问题

我先讲一个特别典型的现象。同一个业务需求，用关系型数据库实现，通常是七八张表，主表加若干明细表，查一个完整对象要 JOIN 四五次；用 MongoDB 实现，往往就是一个集合，一条文档里嵌套三四个数组。这两种做法没有绝对优劣，但背后的思路差异很大：关系型数据库的核心假设是“数据要拆到最小粒度，靠关系组合”，它的强项是一致性和复杂关联查询；文档型数据库的核心假设是“数据按访问方式聚合，一次读到的就是页面要展示的完整对象”。

这个差异直接决定了读写性能的分布。文档模型把“组装”这个动作从查询时提前到了写入时，所以读特别快，一条文档一次磁盘寻址就能拿到全部内容；代价是写入时要维护整条文档，而且如果同一份数据被多个地方嵌入，更新就会变得麻烦。我一般用一个比喻解释：关系型像是乐高积木，所有零件分类放在盒子里，拼什么现取；文档型像是预制好的成品模块，拿来就用，但你想改其中一个部件，得考虑这个部件是不是也被别的模块用着。

理解到这一层，你在建第一个集合的时候就会自然问自己两个问题：这份数据平时是怎么被读的？它会不会被多处共享并且频繁变更？第一个问题决定要不要把子结构嵌进去，第二个问题决定要不要拆成两个集合用引用关联。这两个判断做对了，后面的索引、查询、扩容都会顺很多；做错了，你会在入门第二周就开始怀疑人生。

1.2 快速入门要跨过的四道坎

我把 MongoDB 入门拆成四道坎，顺序不能乱，每一道没跨过去就别急着上下一道。

第一道是环境。装完之后能稳定启动、能用命令行连上、知道数据文件落在哪儿、日志在哪儿看。这道坎看着简单，但新手翻车最多的就是这儿——配置文件格式不对、目录权限不够、端口被占，报错信息又很隐晦。

第二道是建模与写入。搞清楚集合和文档的关系，知道一条文档长什么样，能熟练地插入、更新、删除。重点是更新操作符，很多人只会整条替换，结果并发场景下互相覆盖数据，这种事故我见过不止一次。

第三道是查询与索引。会写条件、会排序分页、会看执行计划。这道坎是分水岭，跨过去的人写出来的服务能扛住业务增长，没跨过去的，上线三个月就开始被慢查询告警追着跑。

第四道是运维底线。开鉴权、配账号、会备份恢复、知道副本集是干什么的。个人练手可以跳过，但只要这套库要放生产环境，这四件事一件都不能省。

1.3 什么场景适合上，什么场景别硬上

这一节是我个人观点，可能跟一些宣传口径不太一样：MongoDB 不是万能的，硬上会很难受。

适合的场景，我总结成三类。一类是结构不固定的数据，比如商品属性，家电有功率、服装有尺码、食品有保质期，用关系型要么开一堆稀疏列，要么搞一张属性表再 JOIN 回来，用文档模型直接把属性塞成一个子文档，读写都干净。二类是读写比例悬殊、且读的时候要整块拿的内容型数据，比如文章、评论树、配置项。三类是快速迭代期的业务，字段天天加，用文档模型改结构几乎零成本，不用写迁移脚本。

不太适合的场景也很明确。强事务、跨多实体的一致性问题，比如账务流水、库存扣减，这类场景关系型数据库的约束和事务机制成熟得多，MongoDB 虽然支持多文档事务，但它的事务有副本集前提，开销也比单文档操作大，拿它硬扛高频转账属于给自己找麻烦。复杂的多维度聚合分析，虽然聚合管道很强，但真要做 BI 级别的多表关联统计，专门的 analytical 引擎更合适。还有数据量很小、结构极其稳定的后台管理类系统，用哪个都行，那就选团队最熟的那个，别为了技术新鲜感增加维护成本。

2. 环境搭建：三种部署姿势与它们的取舍

2.1 单机、容器、云托管怎么选

入门阶段我强烈建议先在本机或一台测试机上跑单机实例，别一上来就折腾集群。原因很实在：分片和副本集的配置会引入大量额外概念，你连基本的增删改查手感都还没建立，就被仲裁节点、配置服务器这些词砸晕，学习曲线直接陡成墙。

三种方式各有适用面。本机直接装适合想搞清楚目录结构、配置文件、启动参数的人，学到的东西最多，缺点是卸载和切版本麻烦。容器方式适合想快速得到一个干净实例、随时推倒重来的人，一条命令起一个，数据目录挂载到宿主机，删了容器数据还在，我平时做演示和写测试用例基本都用这个。云托管适合不想碰运维的团队，但入门阶段用它有个副作用：你看不到磁盘、看不到日志、感受不到连接数和内存的关系，很多底层认知建立不起来。

我的建议是：先用容器起一个练手，把增删改查和索引玩熟；然后在一台测试机上用配置文件手工部署一次，搞清楚目录和参数；最后再决定生产用哪种。这个顺序花不了两天，但省下的返工时间远超两天。

2.2 容器方式实操：五分钟拿到一个可用实例

先确认机器上装了容器运行时，然后执行下面这条命令。我习惯把数据目录挂出来，这样容器删了数据还在，练手时随便折腾也不心疼。

mkdir -p /data/mongo-demo docker run -d \ --name mongo-demo \ -p 27017:27017 \ -v /data/mongo-demo:/data/db \ mongo:7.0

几个参数说明一下。-p 27017:27017把容器端口映射到宿主机，MongoDB 默认端口就是 27017，这个数字记住，后面连接串、防火墙规则都要用。-v那个挂载是关键，容器内的数据目录是/data/db，映射到宿主机后，即使容器被删，数据文件还在。镜像标签我写了7.0而不是latest，这是习惯问题——入门练手无所谓，但只要涉及任何需要复现的环境，永远锁版本，latest这种东西会在某个早上让你莫名其妙地跑不起来。

起来之后确认一下状态：

docker ps | grep mongo-demo docker logs --tail 50 mongo-demo

日志里如果看到类似Waiting for connections和端口号，说明服务已经就绪。如果容器起来几秒就退出，九成是宿主机目录权限问题，docker logs里会有明确的权限拒绝提示，把目录属主改一下或者换个可写路径就行。

2.3 用配置文件部署：把参数摆在明面上

容器跑通之后，我建议一定手工部署一次，因为生产环境大概率是这种方式，而且配置文件里的每一项都对应一个你需要理解的概念。下面是一份最小可用的配置，保存成/etc/mongod.conf：

storage: dbPath: /var/lib/mongo journal: enabled: true systemLog: destination: file path: /var/log/mongo/mongod.log logAppend: true net: port: 27017 bindIp: 127.0.0.1 processManagement: fork: true

逐项说清楚，因为这几行里藏着新手最常踩的坑。dbPath是数据文件目录，必须存在且运行用户有读写权限，这个目录一旦确定就别轻易改，改了要连带迁移数据文件。journal是预写日志，保证掉电后能恢复，生产环境绝对不能关，关掉换来的那点写入性能提升不值得拿数据完整性去赌。bindIp我写的是127.0.0.1，意思是只监听本机。新手为了图方便经常写成0.0.0.0，在没有开鉴权的情况下把这套库暴露在网络上，属于严重的安全隐患，这个习惯一定要从一开始就纠正，需要远程访问就用 SSH 隧道或者内网地址加白名单。

启动命令和执行后的验证：

mongod --config /etc/mongod.conf tail -f /var/log/mongo/mongod.log

日志里出现Waiting for connections就成功了。这一步如果失败，先看日志最后二十行，报错基本都写得很直白：目录不存在、权限不足、端口占用，三种情况占了绝大多数。

2.4 连接串与命令行工具的基本手感

连接工具现在统一用mongosh，老的mongoshell 已经退役，别再照着老教程抄命令。连接本地实例：

mongosh "mongodb://127.0.0.1:27017"

连接串的格式值得单独记一下：mongodb://用户名:密码@主机:端口/数据库?参数。入门阶段不带用户名密码，后面开了鉴权就要补上，而且如果账号建在admin库，还得加authSource=admin，这个参数漏了会出现“认证失败”但账号密码明明没错的诡异情况，我第一次遇到时排查了半小时。

进去之后先熟悉几个命令，都是运维和排查时的常用动作：

db.version() // 看版本 show dbs // 看有哪些库 use shop // 切库，不存在会自动创建 db.stats() // 当前库的统计 db.getCollectionNames()

这里有个反直觉的点要提前说：use shop切换到一个不存在的库不会立刻创建它，只有你往里面写了第一条数据，库才真正落盘。所以新手常困惑“我建了库怎么show dbs看不到”，答案就是你没写数据。

3. 数据建模与增删改查：入门阶段最容易翻车的部分

3.1 集合不是表：嵌入与引用的判断标准

这是入门阶段最关键的一节，我建议多读两遍。

先立一个基本认识：集合对应关系型的表，文档对应行，字段对应列，但这不是一一映射。文档里的字段值可以是嵌套对象，也可以是数组，数组里的元素还能是对象。这个能力是文档模型的核心，也是新手最容易用错的地方。

判断该嵌入还是该引用，我总结成三条可操作的规则。第一，看“一起读”还是“分开读”。如果父对象展示时子数据必然一起出现，比如订单和它的商品明细，嵌入。如果子数据会被独立查询、分页、统计，比如用户和它的全部订单，引用。第二，看“一对一还是一对多，多到什么程度”。一对少量（几十个以内）可以嵌入，一对海量（成千上万）必须引用。嵌入数组无上限增长是文档模型最典型的反模式，因为单条文档有大小上限，而且数组越大，更新和读取的开销越高。第三，看“子数据是不是被多处共享且频繁变更”。共享且高频变更的数据嵌入多份，就会出现改了一处忘了另一处的一致性问题，这种情况老老实实拆集合用引用。

举个具体的。做商品系统，商品的规格参数、图片列表、标签，都是跟着商品一起展示、只属于这个商品、量也不大，直接嵌进商品文档，一次查询拿全，特别舒服。但是商品的评论，数量可能上万，还要支持按时间分页、按点赞排序、单独统计条数，这就是典型的引用场景，评论单独一个集合，用商品 ID 关联。

还有一个坑要提醒：嵌入的层级别太深。三层以上的嵌套会让查询语句和更新操作符变得极难写，也影响可读性。我见过把整个组织架构嵌成十层树的文档，改一个叶子节点要写一长串路径，维护的人苦不堪言。层级超过三层，就该考虑扁平化或者拆集合了。

3.2 插入与查询：从第一条文档开始

先建几条测试数据，后面所有例子都基于这个结构：

use shop db.products.insertOne({ name: "机械键盘", category: "外设", price: 399, stock: 120, tags: ["键盘", "办公"], specs: { layout: "87键", switch: "红轴" }, createdAt: new Date() })

insertOne返回结果里会带上生成的_id。这个字段是 MongoDB 自动加的主键，类型是 ObjectId，由时间戳、机器标识、进程号、计数器拼成，全局唯一且大致有序。有个很重要的实践：不要自己生成字符串当_id，除非你明确需要一个业务主键。用默认的 ObjectId，写入时的索引维护成本最低，分布式下也不会冲突。

批量写入用insertMany，注意它默认是有序插入，中间一条失败就停在那儿，后面的不执行。如果希望失败也继续，加参数{ ordered: false }。这个细节在导入历史数据时特别有用，你不希望一条脏数据卡住整个导入流程。

查询的基本形态是db.集合.find(条件, 投影)。条件为空对象就是全查，但要小心，find({})在大集合上会一次拉一大堆数据回来，命令行直接卡住。生产代码里几乎不存在无条件全查，练手时也养成带limit的习惯。

3.3 更新操作符：整条替换是事故的源头

这一节必须重点讲，因为我见过太多因为更新方式不对导致的数据覆盖事故。

先看错误示范。有些人更新是这样的：先findOne把整条文档查出来，在内存里改几个字段，然后replaceOne或者updateOne把整条写回去。单线程跑没问题，一并发就完了：A 和 B 同时读到同一条文档，A 改了库存，B 改了价格，谁后写谁的版本生效，另一个人的修改直接消失。这就是典型的丢失更新。

正确做法是用更新操作符，只表达“要改哪个字段、怎么改”，让数据库在服务端原子地完成。

db.products.updateOne( { _id: ObjectId("...") }, { $set: { price: 359 }, $inc: { stock: -1 }, $push: { tags: "促销" } } )

$set设置字段值，字段不存在就创建；$inc原子自增，做库存扣减、计数器的标准姿势；$push往数组追加，配合$each可以一次加多个；$addToSet是追加但去重；$pull从数组移除匹配元素；$unset删字段。这几个够覆盖入门阶段八成的更新需求。

再补两个必须知道的点。

upsert。updateOne的第三个参数传{ upsert: true }，意思是“匹配到就更新，没匹配到就按条件加更新内容插入一条”。做幂等写入、做配置项同步时特别顺手，省掉一次查询。

更新数组里的元素。如果数组元素是对象，按条件定位要用位置操作符：

db.orders.updateOne( { _id: ObjectId("..."), "items.sku": "A100" }, { $inc: { "items.$.qty": 1 } } )

这里的$是占位符，代表查询条件里匹配到的那个数组元素的下标。注意它只定位第一个匹配项，要更新全部匹配项得用$[]或者arrayFilters。这个语法新手容易写错，尤其是引号的位置，"items.$.qty"整体是一个字符串，不能写成items.$.qty不加引号。

3.4 投影、排序与分页的正确姿势

查询写对了，还有几个细节决定你写出来的接口是否可用。

投影是第二个参数，用来控制返回哪些字段。{ name: 1, price: 1, _id: 0 }表示只要名字和价格，不要_id。为什么要做投影？一是减少网络传输，一条文档里放个几百 KB 的详情字段，列表页查二十条就是几 MB，纯属浪费；二是覆盖查询的可能，如果查询条件和返回字段都在同一个索引里，数据库可以完全不读文档本体，性能提升非常明显。这条后面讲索引时还会展开。

排序用.sort({ createdAt: -1 })，1 是升序，-1 是降序。注意排序字段如果没有索引，数据量大时会在内存里排，一旦超过内存限制就直接报错，不是变慢，是直接失败。这个错误信息是Sort exceeded memory limit，看到它就该去建索引了。

分页用.skip(n).limit(m)。小数据量没问题，但skip有个致命缺陷：它是“扫描并丢弃”，翻到第一万页时，数据库要先把前面九万多条扫出来扔掉。所以深分页场景不要用skip，改用“游标分页”——记住上一页最后一条的排序字段值，下一页从它之后开始取：

db.products.find({ createdAt: { $lt: lastSeenTime } }) .sort({ createdAt: -1 }) .limit(20)

这个写法在数据量增长后依然稳定，因为它总能走索引定位到起点。做列表接口的时候提前用上，能省掉后面一次重构。

4. 索引与查询性能：入门就该养成的习惯

4.1 索引是怎么工作的，以及怎么建

索引这个东西，用生活化的说法：没有索引，找一条数据就像在一本没有目录的书里逐页翻，数据有多少页就得翻多少页；有索引，相当于先查目录，直接跳到你想要的那一页附近。代价是这本目录本身要占篇幅，而且每次改内容都得同步更新目录。

MongoDB 的索引底层是 B 树结构，默认给_id建了一个唯一索引，其他字段都需要自己建。建索引的语法很直白：

db.products.createIndex({ category: 1 }) db.products.createIndex({ category: 1, price: -1 }) db.products.createIndex({ tags: 1 })

数字 1 和 -1 表示排序方向。单字段索引方向无所谓，因为 B 树可以双向遍历；复合索引的方向就有意义了，它要跟你查询里的排序方向匹配，才能既走索引过滤又走索引排序，避免额外的内存排序。

还有几种特殊类型值得入门就知道。唯一索引加{ unique: true }，用来约束业务上的唯一性，比如手机号、订单号。TTL 索引用来做过期自动清理，比如会话表、验证码表，建索引时指定expireAfterSeconds，后台线程会定期删除过期文档，省掉自己写定时任务的麻烦。数组字段索引叫多键索引，给数组建索引后，数组里每个元素都会进索引，所以{ tags: 1 }能让find({ tags: "键盘" })走索引。

建索引有几个操作上的注意点。生产环境给大集合建索引，默认是前台阻塞式还是后台式，取决于版本，新版本已经是非阻塞的但依然会消耗资源，建议放在低峰期。另外索引不是越多越好，每个索引都会拖慢写入速度、占用内存和磁盘，一张集合上超过五六个索引就该审视一下是不是设计有问题。

4.2 用 explain 看懂一次查询走了什么路

这是我认为入门阶段最应该养成的一个习惯：写完一条稍微复杂点的查询，顺手explain一下。

db.products.find({ category: "外设", price: { $lt: 500 } }) .sort({ createdAt: -1 }) .explain("executionStats")

输出很长，但入门阶段只看三个数就够了。

第一，winningPlan里的 stage。如果看到COLLSCAN，说明全表扫描，数据量一大就完蛋，必须建索引。看到IXSCAN才是走了索引。看到FETCH表示从索引里拿到位置后又回文档取内容，正常。看到SORT且不在索引里，说明排序没走索引，内存排序，量大就炸。

第二，nReturned和totalKeysExamined、totalDocsExamined的关系。理想状态是三个数接近：扫描了多少索引键、看了多少文档、返回了多少条，都差不多，说明索引很精准。如果totalDocsExamined是nReturned的一百倍，说明扫描了大量文档再过滤，索引的选择性不够，需要调整字段顺序或者加字段。

第三，executionTimeMillis。这个数字受缓存影响很大，第一次跑和第二次跑可能差十倍，别只看一次。我一般会连续跑几次，看稳定后的值。

解释一下前面那条查询为什么需要复合索引。条件里有category等值匹配和price范围匹配，排序用createdAt。如果只建{ category: 1 }，能过滤出外设类，但还要回文档取价格做过滤，再在内存里排序。如果建{ category: 1, createdAt: -1, price: 1 }，就能一路走索引：先按 category 等值定位，然后按 createdAt 逆序直接取，price 作为过滤条件在索引里判断。差别在百万级数据上是很明显的。

4.3 复合索引的字段顺序：ESR 原则

复合索引的字段顺序不是随便排的，业界有个比较通用的经验叫 ESR：Equality（等值）→ Sort（排序）→ Range（范围）。

道理不难理解。索引是一棵排好序的树，你的查询条件在树上走得越“连贯”，效率越高。等值条件能把范围一下子收窄到一个点，排在前面最划算；排序字段紧跟着等值字段，能保证在这个点后面的数据天然有序，不用额外排；范围条件会切断后续字段的可用性，所以放最后。

举个具体例子。查询是：状态为“已完成”、按创建时间倒序、金额大于 100。对应的索引应该是：

db.orders.createIndex({ status: 1, createdAt: -1, amount: 1 })

反过来，如果写成{ amount: 1, status: 1, createdAt: -1 }，amount 是范围条件，排在第一位会导致后面两个字段在索引里无法有效利用，性能差一大截。这种错误特别隐蔽，因为查询能出结果，只是慢，不做 explain 根本发现不了。

还有一条经验：索引前缀可以复用。建了{ a: 1, b: 1, c: 1 }，那么按a查、按a + b查都能用上这个索引，但按b单查用不上。所以设计复合索引时，把最常用的单字段查询条件放在最左边，能省掉一个单独的索引。

5. 权限、备份与生产化前的必修课

5.1 开启鉴权与最小权限账号

本地练手不开鉴权没问题，但只要这套库放在能被别人访问的地方，第一件事就是开鉴权。步骤不复杂，但顺序不能错。

先在不开鉴权的状态下启动，创建管理员账号：

use admin db.createUser({ user: "rootAdmin", pwd: "换成一个足够长的密码", roles: [{ role: "userAdminAnyDatabase", db: "admin" }] })

然后停掉服务，在配置文件里加上：

security: authorization: enabled

重启后，任何操作都需要认证。连接时带上账号：

mongosh "mongodb://rootAdmin:密码@127.0.0.1:27017/admin"

接着给应用建专用账号，遵循最小权限原则，只给它需要的库和操作：

use admin db.createUser({ user: "shopApp", pwd: "另一个足够长的密码", roles: [{ role: "readWrite", db: "shop" }] })

这里有个高频坑：应用账号建在shop库下，连接串却指向admin，或者反过来，导致认证失败。记住规则——账号属于哪个库，连接串的authSource就写哪个库；如果账号建在admin，连接串路径写业务库、authSource写admin，两者可以不同。我一般统一把应用账号建在业务库里，连接串路径和authSource都写业务库，最不容易出错。

角色选择上，readWrite够应用日常用了，别图省事给root。数据库账号权限过大，一旦应用被攻破，损失是整个实例而不只是一个库。

5.2 备份与恢复：两条命令保命

备份这件事，我见过太多团队在出事之后才想起来做。MongoDB 自带的逻辑备份工具是mongodump和mongorestore，够中小规模用。

mongodump \ --uri="mongodb://shopApp:密码@127.0.0.1:27017/shop?authSource=shop" \ --out=/backup/mongo/2024-06-01

恢复：

mongorestore \ --uri="mongodb://shopApp:密码@127.0.0.1:27017/shop?authSource=shop" \ --dir=/backup/mongo/2024-06-01

几个实操要点。--out指定的目录会按库名建子目录，里面是 BSON 文件和元数据，所以备份目录要按日期分，别互相覆盖。恢复时可以加--drop表示先删掉现有集合再导入，做灾难恢复时一般都要加，否则会跟已有数据混在一起。数据量大的话，mongodump会明显拖慢实例，建议在低峰期跑，或者用文件系统快照的方式做物理备份。

逻辑备份的局限也要清楚：它是逐条读出来再写回去的，数据量到几十 GB 以上，耗时会变得不可接受，恢复时间更长。规模再往上就得考虑快照或者专门的备份方案。但对入门和中小业务来说，每天定时跑一次mongodump，备份文件传到另一台机器，已经能挡住绝大多数意外。

注意：备份做完一定要做一次恢复演练。我见过备份脚本跑了两年从没报错，真出事时发现目录是空的，因为权限问题一直静默失败。备份的有效性只能靠恢复来证明。

5.3 副本集与事务：什么时候必须迈这一步

单机实例有个硬伤：机器一挂，服务就断，而且没有自动故障转移。副本集解决的正是这个问题，多台机器各存一份数据，主节点负责写，从节点同步，主节点挂了自动选举一个新的。

入门阶段要不要碰副本集？我的判断是：只要你需要多文档事务，就必须上副本集，因为事务功能只在副本集或分片集群上可用，单机不支持。另外只要业务不能接受几小时的停机，也该上。搭一个单节点副本集做开发测试环境，是很好的过渡：

rs.initiate({ _id: "rs0", members: [{ _id: 0, host: "127.0.0.1:27017" }] })

连接串要相应改成mongodb://127.0.0.1:27017/?replicaSet=rs0，漏掉replicaSet参数会出现“不是副本集成员”的报错。有了副本集，多文档事务就能这么写：

const session = db.getMongo().startSession() session.startTransaction() try { const orders = session.getDatabase("shop").orders const stock = session.getDatabase("shop").stock orders.insertOne({ /* ... */ }) stock.updateOne({ sku: "A100" }, { $inc: { qty: -1 } }) session.commitTransaction() } catch (e) { session.abortTransaction() throw e }

但要提醒一句：事务不是免费的。它持锁、占资源，长事务会拖累整个实例。能用单文档原子操作解决的问题，别上事务。比如库存扣减，如果库存就在商品文档里，一条$inc加条件更新就够了，根本不需要事务：

db.products.updateOne( { _id: id, stock: { $gte: 1 } }, { $inc: { stock: -1 } } )

这一条语句本身就是原子的，判断和扣减一次完成。我倾向于把数据设计成“一个业务动作对应一条文档的原子更新”，这样既不用事务，性能又好。

6. 常见问题与排查实录

6.1 连不上、起不来：一条固定的排查路径

新手最先撞上的就是这两类问题。我按发生频率排了个顺序，照着走基本能定位。

服务起不来。先看日志，这是唯一可靠的信息源。日志位置在配置文件里写着，如果用容器，docker logs 容器名。三种典型报错：Address already in use是端口被占，用lsof -i:27017找到占用进程处理掉，或者改端口；Permission denied是数据目录或日志目录权限不对，把属主改成运行用户；Unrecognized option是配置文件格式错了，YAML 对缩进极其敏感，两个空格和四个空格混用、用了 Tab，都会报这个，检查时直接看报错里提到的行号。

连不上。分三种情况。服务没起来，先按上面处理。服务起来了但拒绝连接，看bindIp配置，写127.0.0.1就只能本机连，远程连必然失败。能连上但认证失败，检查账号所属的库和连接串里的authSource是否一致，这是最高频的原因，其次是密码里包含特殊字符没做 URL 编码，比如@、:、/出现在密码里，必须转义。

连上了但操作报错。最常见的是权限不足，报错信息里会明确写出缺少哪个 action，对照角色表补权限。还有一种容易忽略的情况是连接数打满，报错类似too many open connections，这时候要去看应用侧的连接池配置。

6.2 典型问题速查表

下面这张表是我从实际排查记录里整理出来的，覆盖了入门阶段八成的报错。

表格里最后两条值得多说两句。删除数据不等于释放磁盘，存储引擎会把空间留着给后续写入复用，所以你会看到“数据删了一半，磁盘一点没降”。这是正常设计，不是 bug，别急着去折腾。备份静默失败则是真正危险的那类问题，脚本退出码可能被管道吞掉，一定要显式检查目录里有没有生成文件。

6.3 我踩过的几个坑，以及几条个人建议

先说几个具体的坑。

坑一：用字符串存日期。刚开始图省事，时间字段存成"2024-06-01 10:00:00"这样的字符串。当时觉得挺直观，后来要做时间范围查询、要按时间排序、要算时间差，全部抓瞎——字符串比较是按字典序的，跨月跨年就会出错，而且占空间比日期类型大。正确做法是用原生的日期类型，命令行里new Date()创建，驱动里用对应的日期对象。这个坑一旦踩了，数据量大了改起来极其痛苦，因为要做全量数据迁移。

坑二：把所有东西塞进一条文档。有个同事做聊天功能，把一个会话的全部消息做成一个数组嵌在会话文档里。测试阶段几十条消息，跑得好好的。上线两周，热门群聊几千条消息，每次发一条新消息都要重写整条文档，写入延迟肉眼可见地上升，读取时只要拉会话详情就带出几 MB 数据。后来改成消息单独成集合、按会话 ID 加时间建复合索引，问题立刻消失。教训就是：无界增长的数组，一律拆出去。

坑三：忽略写入关注和读取关注。默认配置下，写入是“发出去就算成功”，读取可能读到还没同步的数据。单机环境没感觉，一旦上了副本集，主节点写完立刻挂了、数据还没同步到从节点，就会丢数据。对数据安全性有要求的业务，写入要显式指定多数节点确认。这个参数在内网低延迟环境下开销可以接受，值得提前配好。

坑四：拿skip做深分页。前面提过，这里再强调一次，因为它太常见了。后台列表页翻到几百页之后越来越慢，很多人第一反应是加索引，其实索引没问题，是skip的机制决定的。改成游标分页，问题从根上解决。

再说几条我个人的建议，算是这些年攒下来的经验。

入门阶段别急着上集群和分片。我见过太多人在本地玩了两天就想搭分片集群，结果连副本集选举都没搞明白，配置出来的环境各种诡异问题，最后连最基本的增删改查都没练熟。先把单机玩透，把索引和执行计划看明白，再往外扩，这个顺序带来的效率差距是数量级的。

建模的时候，拿一张纸画出你最主要的三个查询场景，然后倒推文档结构。这件事花十分钟，能省掉后面几个月的返工。文档型数据库的建模核心不是“数据长什么样”，而是“数据怎么被用”。你把查询想清楚了，结构自然就出来了。

还有一点，把explain变成肌肉记忆。我现在写稍微复杂一点的聚合或者带排序的查询，都会顺手跑一次，看看有没有 COLLSCAN，看看扫描比。这个习惯养成之后，很多性能问题在上线前就被消灭了，根本轮不到监控告警来提醒你。

最后说个观察：MongoDB 入门真正的门槛不在命令，而在思维方式的切换。你什么时候能自然地想到“这个子结构应该嵌进去，因为它总是跟父对象一起读”，而不是下意识地去建关联表，什么时候算是真的入门了。剩下的语法、参数、运维命令，都是在这个基础上查文档就能补齐的东西。我带的几个人里，凡是先花半天把模型想清楚的，后面几乎不用我再指导；上来就抄代码的，往往两周后回来问同一批问题。这个差别，值得你在动手之前多花那半天。