1. 为什么文档型数据库值得你花时间搞明白
第一次接触 MongoDB 是在一个内容管理系统的后台重构项目里。当时用的关系型数据库，产品经理隔三差五就要加字段、改结构，每次都要写迁移脚本、改表结构，开发效率被拖得很惨。后来团队里有人提议试试文档型数据库，我花了一个周末把 MongoDB 从安装到增删改查完整跑了一遍，才发现这东西在应对"结构不确定"的场景时，确实有它独到的优势。
MongoDB 是一个面向文档的 NoSQL 数据库，它把数据存成类似 JSON 的 BSON 格式，每条记录叫一个"文档"，一堆文档组成"集合"。它不要求你提前定义表结构，字段可以随时增减，嵌套对象和数组直接往里塞就行。这套模型特别适合内容管理、日志采集、用户画像、物联网设备数据这类"字段经常变、结构不规整"的场景。如果你是从关系型数据库转过来的开发者，或者正在为某个灵活数据模型选型，这篇文章会带你从零把 MongoDB 装起来、跑通增删改查，并且把每一步背后的逻辑讲清楚。
我写这篇的出发点很直接：网上很多教程只告诉你敲什么命令，却不告诉你为什么这么敲、踩了坑怎么爬出来。我会把安装过程中容易翻车的地方、增删改查里那些反直觉的行为、以及我实际用下来觉得最值得注意的经验，都摊开讲一遍。读完你至少能做到：在自己机器上装好 MongoDB，用命令行和代码两种方式完成数据的增删改查，并且知道什么场景该用它、什么场景别硬上。
2. 安装 MongoDB：选对方式和版本比敲命令更重要
2.1 先想清楚你要装哪个版本、装在哪
MongoDB 的版本迭代挺快，社区版（Community）免费，企业版（Enterprise）收费。个人学习和绝大多数中小项目，社区版完全够用。版本号方面，我建议选当前稳定版的主线，别去追最新的开发版，也别用太老的版本——太老的版本可能缺少一些现代驱动要求的特性，比如事务支持、聚合管道的新阶段等。
安装方式大致分三类：包管理器安装（apt、yum、brew）、官方压缩包手动安装、以及容器方式运行。我个人的选择逻辑是这样的：
- 本地开发机、想长期用：优先用包管理器，升级卸载都方便。
- 服务器部署、需要精确控制版本和配置：用官方压缩包，自己管理数据目录和配置文件。
- 临时测试、想快速起一个干净环境：用容器，一条命令搞定，用完就删。
这里要提醒一句，不管你用哪种方式，数据目录和日志目录一定要提前规划好。MongoDB 默认会把数据放在/data/db，但这个目录在很多系统上默认不存在，直接启动会报错。我见过太多人第一次启动就卡在这里，以为是安装失败，其实只是目录没建。
2.2 包管理器安装的完整流程与常见报错
以常见的 Linux 发行版为例，用包管理器安装的流程大致是：先导入官方的软件源签名密钥，再把软件源地址加到系统源列表里，然后更新源、执行安装。这几步的顺序不能乱，尤其是密钥导入必须在添加源之前或同时完成，否则更新源时会因为无法验证签名而报错。
安装完成后，MongoDB 通常会被注册成一个系统服务。你可以用服务管理命令启动它，并设置开机自启。启动之后，用systemctl status看一下服务状态，确认是 active 而不是 failed。如果失败了，第一件事是去看日志，日志里通常会明确告诉你失败原因，比如端口被占用、数据目录权限不对、配置文件语法错误等。
我踩过的一个典型坑是权限问题：手动创建的数据目录，属主是 root，但 MongoDB 服务是以 mongodb 用户运行的，结果就是服务起不来，日志里报 permission denied。解决办法很简单，把数据目录和日志目录的属主改成 mongodb 用户即可。这个坑在容器环境里反而不容易出现，因为容器里的用户和目录权限通常是配套设置好的。
还有一个容易被忽略的点是端口占用。MongoDB 默认监听 27017 端口，如果你机器上已经跑了一个 MongoDB 实例，再起一个就会冲突。这时候要么改端口，要么先把旧的停掉。改端口在配置文件里改net.port就行，但改完记得客户端连接时也要指定新端口。
2.3 手动安装与容器方式的关键差异
手动安装的灵活性最高，但需要你自己处理的事情也最多。下载对应平台的压缩包，解压到一个你喜欢的目录，然后创建数据目录和日志目录，写一个配置文件，最后用mongod命令带上配置文件启动。配置文件里至少要指定dbPath（数据目录）、logPath（日志文件）、port（端口）这几项。手动安装的好处是版本完全可控，配置文件一目了然，出问题好排查。
容器方式则是另一套思路。你不需要在宿主机上装任何 MongoDB 相关的东西，只需要拉一个镜像、映射端口、挂载数据卷就行。这里的关键是数据卷挂载：如果不挂载，容器一删数据就没了。挂载的时候要注意宿主机目录的权限，容器内的 MongoDB 用户需要有写权限，否则同样会启动失败。容器方式特别适合快速验证和临时环境，但生产环境用容器跑数据库需要更谨慎地考虑持久化和备份策略。
不管哪种方式，装完之后都建议做一件事：用命令行客户端连上去，执行一个最简单的命令确认服务正常。这个动作花不了几秒钟，但能帮你把"装好了"和"能用了"这两件事区分开。
3. 连上数据库之后，先搞懂它的"语言体系"
3.1 库、集合、文档：三层结构怎么理解
MongoDB 的数据组织是三层：数据库（database）下面有集合（collection），集合里面是文档（document）。这个层级和关系型数据库的"库-表-行"很像，但有个本质区别：关系型的表结构是强约束的，每行字段必须一致；而 MongoDB 的集合不强制文档结构一致，同一个集合里的文档可以有完全不同的字段。
这个区别带来的直接好处是演进成本低。比如你做一个商品系统，一开始商品只有名称和价格，后来要加规格、加图片、加标签，在关系型数据库里你得改表结构、写迁移；在 MongoDB 里，你直接往新文档里加字段就行，老文档不受影响，代码里读取时做好缺省处理即可。
但这也带来一个需要警惕的地方：结构自由不等于可以乱来。如果同一个集合里的文档结构差异过大，查询和索引会变得很麻烦。我的经验是，同一个集合内的文档，核心字段应该保持一致，差异化的部分放在可选的嵌套字段里。这样既保留了灵活性，又不至于让数据变成一团乱麻。
3.2 用命令行客户端做第一次交互
装好服务之后，用自带的命令行客户端连上去。连接命令很简单，默认连本地的 27017 端口。连上之后你会看到一个交互式提示符，可以直接敲命令。
第一件事通常是看看有哪些数据库，用show dbs。你会看到几个默认库，比如 admin、config、local，这些是系统库，别去动它们。然后你可以用use 库名切换到一个库，如果这个库不存在，MongoDB 不会立刻创建它，而是等你第一次往里写数据时才真正创建。这个"延迟创建"的行为很多人第一次会困惑，以为use没生效，其实是对的。
接着可以看看当前库里有哪些集合，用show collections。新库自然是空的。到这里，你已经完成了"连上数据库"这个动作，接下来就是往里写数据了。
3.3 命令行和代码操作的关系
命令行客户端适合做快速验证、临时查询、管理操作。但实际项目里，你更多是用某种编程语言的驱动来操作。不同语言的驱动 API 风格不同，但核心概念是一致的：连客户端、选库、选集合、执行操作。
我建议的学习路径是：先用命令行把每个操作跑一遍，理解它的语义和返回结果，然后再去看对应语言的驱动怎么写。这样你在写代码时，脑子里是有底的，遇到问题也知道是驱动用法问题还是数据库本身的问题。反过来，如果一上来就写代码，出了错你很难判断是语法问题、连接问题还是数据问题。
4. 插入数据：看似简单，细节全在返回结果里
4.1 插入单条与多条文档的写法差异
插入单条文档用insertOne，插入多条用insertMany。命令行的写法是db.集合名.insertOne({...})和db.集合名.insertMany([{...},{...}])。注意多条插入时参数是一个数组，这个数组里每个元素是一个文档。
这里有个细节值得说：插入时如果不指定_id字段，MongoDB 会自动生成一个 ObjectId 作为主键。这个 ObjectId 是一个 12 字节的值，包含了时间戳、机器标识、进程标识和随机数，全局唯一。你当然可以自己指定_id，但除非有特殊需求，否则建议让数据库自动生成，省心且不会冲突。
多条插入时，如果其中某一条出错（比如_id重复），默认行为是遇到错误就停止，前面成功的已经写入，后面的不再执行。这个行为可以通过选项调整，让它在出错时继续插入剩余文档。实际使用中，如果你在做批量导入，建议开启"有序插入"的相反模式，也就是无序插入，这样一条失败不影响其他条，最后统一看哪些失败了再处理。
4.2 插入操作的返回结果怎么读
插入操作的返回结果里，最有用的是insertedId（单条）或insertedIds（多条），以及acknowledged字段。acknowledged为 true 表示写操作被数据库确认了。如果是多条插入，还会告诉你成功插入了多少条。
我特别想强调的是：不要只看命令有没有报错，要看返回结果里的确认信息。有些情况下命令不报错，但实际没写进去（比如写关注级别设置得很低时）。养成看返回结果的习惯，能帮你及早发现配置问题。
另外，插入的文档如果包含嵌套对象或数组，直接写就行，不需要像关系型数据库那样拆成多张表。比如一个用户文档里直接放一个地址对象、一个标签数组，这是 MongoDB 的常规用法。这种"把关联数据放在一起"的建模方式，在读取时往往一次查询就能拿到完整数据，减少了关联查询的开销。
4.3 插入时容易踩的几个坑
第一个坑是字段名冲突。文档里的字段名不能以$开头，也不能包含点号（.），因为这两个符号在 MongoDB 里有特殊含义（$用于操作符，点号用于路径访问）。如果你从别的系统导入数据，字段名里带了这些符号，插入会失败。
第二个坑是文档大小限制。单条文档有大小上限（目前是 16MB），超过就会插入失败。如果你要存大文件，应该用 GridFS 这类专门机制，而不是硬塞进普通文档。
第三个坑是类型不一致。同一个字段，这条文档存的是数字，那条存的是字符串，查询时就会出问题。比如你按数值范围查，字符串类型的记录就匹配不上。我的建议是，对核心字段的类型要有约定，写入前做校验。
5. 查询数据：条件、投影、排序、分页一次讲透
5.1 基本查询与条件操作符
查询用find方法，参数是一个查询条件文档。最简单的查询是传一个空对象{}，表示查全部。带条件的查询，比如查年龄等于 25 的，写{age: 25}。
但实际查询很少只有等值条件。MongoDB 提供了一套条件操作符，常用的有：
| 操作符 | 含义 | 示例 |
|---|---|---|
$gt | 大于 | {age: {$gt: 25}} |
$gte | 大于等于 | {age: {$gte: 25}} |
$lt | 小于 | {age: {$lt: 25}} |
$in | 在列表中 | {status: {$in: ["A","B"]}} |
$ne | 不等于 | {status: {$ne: "C"}} |
$exists | 字段是否存在 | {email: {$exists: true}} |
多个条件默认是"与"的关系，直接写在同一个文档里就行。如果要"或"，用$or操作符，参数是一个数组，数组里每个元素是一个条件文档。
这里有个反直觉的点：查询条件里的字段顺序不影响结果，但影响索引使用。如果你建了复合索引，查询条件的字段顺序要和索引顺序匹配才能充分利用索引。这个在数据量大的时候差别很明显，后面讲索引时再展开。
5.2 投影：只取你需要的字段
默认情况下，find会返回文档的所有字段。但很多时候你只需要其中几个字段，这时候用投影（projection）来指定。投影是find的第二个参数，格式是{字段名: 1}表示包含，{字段名: 0}表示排除。
有个规则要记住：除了_id字段，包含和排除不能混用。也就是说，你不能写{name: 1, age: 0}，这是非法的。_id是特例，你可以写{name: 1, _id: 0}表示只要 name、不要 _id。
投影的价值在数据量大时特别明显。一个文档如果有几十个字段，你每次只查其中三五个，网络传输和内存占用都会小很多。养成按需投影的习惯，是提升查询效率的一个低成本手段。
5.3 排序、限制与分页的正确姿势
排序用sort，参数是{字段名: 1}表示升序，{字段名: -1}表示降序。限制返回条数用limit，跳过若干条用skip。分页的经典写法就是skip加limit组合。
但这里有个性能陷阱：skip在数据量大时很慢，因为它需要扫描并丢弃前面跳过的文档。比如你翻到第 1000 页，每页 20 条，skip就是 20000，数据库要先把前 20000 条找出来再丢掉，代价很高。
更好的分页方式是基于游标的分页，也就是用上一页最后一条记录的某个有序字段值作为下一页的查询起点。比如按_id排序，下一页就查_id大于上一页最后一条_id的记录。这种方式不管翻到第几页，查询代价都差不多。当然，它不支持随机跳页，适合"下一页"式的无限滚动场景。
5.4 查询结果的处理与游标概念
find返回的是一个游标（cursor），不是直接把所有结果都加载到内存。游标是惰性的，你遍历它的时候才真正去取数据。命令行客户端会自动帮你遍历并打印前若干条，但在代码里你需要显式地遍历游标。
游标有个默认的超时时间，如果长时间不操作，服务端会把它关掉。在代码里处理大量数据时，要注意及时遍历完或者手动关闭游标，避免资源泄漏。另外，如果结果集非常大，遍历过程中可能会分批从服务端拉取，这个对使用者是透明的，但你要知道它不是一次性全拉回来的。
6. 更新与删除：精确操作，避免误伤
6.1 更新操作符：$set、$unset、$inc 的用法
更新文档用updateOne或updateMany。第一个参数是筛选条件，第二个参数是更新内容。更新内容必须用更新操作符包裹，否则会直接用新文档替换掉旧文档（这是新手最容易犯的错）。
常用的更新操作符：
$set：设置字段值，字段不存在则创建。$unset：删除字段。$inc：对数值字段做增减，比如计数器场景。$push：往数组里追加元素。$pull：从数组里移除匹配的元素。
我重点说一下$set和直接替换的区别。如果你写updateOne({name:"张三"}, {age: 30})，这不是把张三的年龄改成 30，而是把整个文档替换成{age: 30}，其他字段全没了。正确写法是updateOne({name:"张三"}, {$set: {age: 30}})。这个坑我见过太多人踩，而且数据被覆盖后很难恢复，一定要记牢。
6.2 更新时的匹配与 upsert 选项
updateOne和updateMany的区别在于，前者只更新匹配到的第一条，后者更新所有匹配的。如果你不确定会匹配到几条，用updateOne更安全。
还有一个有用的选项是upsert。设置upsert: true后，如果筛选条件没匹配到任何文档，就会插入一条新文档。这个在"有则更新、无则插入"的场景下很方便，比如同步外部数据时。但要注意，upsert 插入的新文档是由筛选条件和更新内容合并而成的，字段的最终形态需要你心里有数。
更新操作的返回结果里，matchedCount告诉你匹配到几条，modifiedCount告诉你实际改了几条。这两个数可能不一样，比如你$set的值和原值相同，匹配到了但没实际修改。看这两个数能帮你判断更新是否如预期。
6.3 删除操作：deleteOne 与 deleteMany 的取舍
删除用deleteOne和deleteMany，参数都是筛选条件。和更新一样，deleteOne只删第一条匹配的，deleteMany删所有匹配的。
删除操作最需要警惕的是筛选条件写错导致误删。我的习惯是：在执行删除前，先用同样的条件跑一次find，确认查出来的确实是我要删的数据，然后再把find换成delete。这个习惯看起来多了一步，但能避免很多灾难性的误操作。
另外，删除集合里所有文档可以用deleteMany({})，但这不会删除集合本身，集合的索引等元信息还在。如果要连集合同索引一起删，用drop方法。删除数据库则用dropDatabase。这几个操作的破坏性依次递增，执行前一定要确认清楚。
6.4 批量操作的性能考量
批量更新或删除时，如果数据量很大，一次性执行可能会占用大量资源，甚至阻塞其他操作。我的经验是分批处理：每次处理一批（比如 1000 条），处理完再处理下一批。这样对数据库的压力更平滑，也方便在中间观察进度和中断。
分批的实现方式可以是按_id范围切分，也可以是按某个时间字段切分。关键是每批的筛选条件要能覆盖且不重叠，避免漏处理或重复处理。这个思路和前面讲的分页查询是一脉相承的。
7. 从命令行到代码：把增删改查落到实际项目里
7.1 驱动选择与连接管理
实际项目里你不会用命令行客户端，而是用对应语言的驱动。主流语言都有官方驱动，API 风格大同小异。选驱动时优先用官方的，社区驱动的维护及时性和兼容性往往不如官方。
连接管理是第一个要注意的点。不要每次操作都新建连接，而是创建一个客户端实例，全局复用。客户端内部维护了连接池，复用能大幅降低开销。客户端实例通常在应用启动时创建，应用关闭时销毁。
连接字符串里可以配置不少参数，比如连接超时、读写关注级别、连接池大小等。默认值在大多数场景下够用，但如果你遇到连接超时或性能问题，这些参数是排查方向之一。
7.2 用代码实现一套完整的增删改查
以常见的脚本语言为例，完整流程是：引入驱动、创建客户端、连接、选库选集合、执行操作、关闭客户端。插入用insertOne/insertMany，查询用find配合条件文档，更新用updateOne/updateMany配合更新操作符，删除用deleteOne/deleteMany。
代码里和命令行最大的不同是异步处理。很多语言的驱动是异步 API，操作返回的是 Promise 或类似结构，你需要 await 或者用回调处理。忘记 await 是新手常见错误，表现为操作"没生效"，其实是异步任务还没执行完程序就往下走了。
另外，代码里处理查询结果时，游标需要显式遍历。不同驱动的遍历方式不同，有的是toArray()一次性转数组，有的是for await逐条处理。数据量大时优先用逐条处理，避免一次性加载到内存。
7.3 错误处理与连接关闭
代码里一定要做错误处理。数据库操作可能因为网络问题、权限问题、数据问题等各种原因失败，不处理的话程序会直接崩。常见的做法是用 try-catch 包裹操作，根据错误类型决定是重试、记录日志还是向上抛出。
连接关闭也别忘。虽然进程退出时连接通常会被系统回收，但显式关闭是更好的习惯，尤其是在长驻服务里。关闭客户端会释放连接池资源，避免连接泄漏。
8. 几个我实际用下来觉得最值得注意的经验
8.1 什么时候该用 MongoDB，什么时候别硬上
MongoDB 适合的场景：数据结构灵活多变、读写模式以文档为单位、需要快速迭代、数据量中等偏大但不需要复杂事务。典型如内容管理、用户配置、日志、商品目录。
不太适合的场景：需要多表关联的复杂事务、强一致性的金融账务、需要复杂 SQL 分析的报表。这些场景关系型数据库更成熟。我的原则是：如果数据模型天然是文档形态、关联需求少，优先考虑 MongoDB；如果关联复杂、事务要求高，老老实实用关系型数据库。别因为 MongoDB 时髦就硬套。
8.2 索引不是越多越好
MongoDB 支持索引，合理建索引能大幅提升查询速度。但索引本身占空间，写入时也要维护索引，所以不是越多越好。原则是：为高频查询的字段建索引，为排序字段建索引，复合索引的字段顺序要匹配查询模式。
建索引前先用explain看看查询计划，确认是否走了索引、走了哪个索引。没建索引的查询在大数据量下会全集合扫描，慢得让你怀疑人生。但也不要盲目给每个字段都建索引，写入性能会受影响。
8.3 数据建模的几个实用原则
第一，把一起读的数据放在一起。如果两个数据总是同时被查询，就嵌入在同一个文档里，避免关联。第二，数组别无限增长。如果一个数组字段会不断追加元素，考虑拆成独立集合，否则文档会越来越大，最终撞上 16MB 上限。第三，核心字段保持一致。同一集合的文档，核心字段的类型和含义要统一，差异化的部分放可选字段。
8.4 备份和监控别等到出事才想起来
MongoDB 自带备份工具，可以导出整个库或指定集合。生产环境一定要有定期备份策略，并且定期验证备份能恢复。监控方面，关注连接数、内存使用、慢查询这几个指标。慢查询日志能帮你发现哪些查询需要优化，是排查性能问题的重要入口。
我见过有团队上线几个月没做过备份，结果一次误操作删了集合，数据全没了。这种教训太惨痛，备份这件事，宁可备而不用，不可用而不备。
9. 写在最后的一点个人体会
从第一次装 MongoDB 到现在，我用它做过内容系统、日志采集、配置中心等好几个项目。最大的感受是：它的学习曲线前段很平缓，后段很陡峭。装起来、跑通增删改查，一个下午就够了；但要真正用好，把数据建模、索引、分页、批量操作这些细节都处理到位，需要在实际项目里反复打磨。
如果你是刚接触，我的建议是别只看文档，一定要自己动手把每个操作跑一遍，尤其是那些"反直觉"的地方——比如更新必须用操作符、skip分页的性能问题、文档大小限制。这些坑自己踩一遍，比看十遍文档记得都牢。等你把基础操作都跑顺了，再去研究聚合管道、事务、副本集这些进阶内容，会顺畅很多。
