1. 先搞清楚MongoDB是什么再动手
不少人在命令行敲下mongod看到花花绿绿的日志时，心里其实还在嘀咕：MongoDB到底跟MySQL差在哪里？如果带着MySQL的惯性思维去学MongoDB，十个有八个会卡在"表结构怎么设计"这个问题上。我的建议是：先把脑子里那套关系型数据库的框架放一放，MongoDB的底层逻辑完全不同，它不是"表"，而是"集合"；不是"行"，而是"文档"。
MongoDB属于NoSQL家族里的文档型数据库，核心存储单位是BSON格式的文档，说白了就是JSON的二进制变体。每个文档可以拥有不同的字段，同一个集合里不会强制要求结构一致，这正是它在面对快速变化的需求时比MySQL灵活的地方。你不需要预先定义表结构，不需要写CREATE TABLE，插进去的数据长什么样，它就长什么样。
这篇内容适合谁？如果你是刚接触MongoDB的初学者，或者在公司里被迫接手一个MongoDB项目但之前只用过MySQL，这篇文章能帮你把安装、配置、增删改查、查询、聚合、安全这一整条链路走通。如果你连MongoDB都没装过，那更没问题，我们从环境搭建开始讲，把我踩过的坑顺便也指给你看。
另外提一句，很多人接触MongoDB是从"头歌"平台的任务开始的，包括"初识MongoDB""MongoDB数据库基本操作""MongoDB数据库安全"这类题目。这些练习任务本质上就是在倒逼你动手去敲命令，和我下面要讲的实操路子完全一致。所以不管你是为了提高课程分数，还是为了干活，看这篇都够用。
2. 安装部署：真机实操与踩坑记录
2.1 Linux环境安装MongoDB 4.4/6.x的完整套路
安装MongoDB我首选Linux服务器，原因很简单：生产环境基本都是Linux，而且Linux下的安装方式比Windows干净得多。这里以CentOS 7/Ubuntu 20.04为例，讲一套通用的安装流程。
在CentOS上，先配置MongoDB官方yum源。注意，MongoDB从4.4之后版本号跳动较大，每个大版本有独立的源配置。比如安装4.4版本，需要创建/etc/yum.repos.d/mongodb-org-4.4.repo文件，写入：
[mongodb-org-4.4] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc然后执行：
yum install -y mongodb-orgUbuntu/Debian系统则需要先导入公钥再添加源，操作稍有不同，但思路一致。装完之后，先别急着改配置，直接用默认配置启动一次试试：
systemctl start mongod systemctl status mongod如果启动成功，mongo命令就能连上默认的localhost:27017。但这里有个新手最容易踩的坑：CentOS默认开启了SELinux，可能会拦截MongoDB的日志文件读写，导致启动时报权限错误。我当时排查了半天，最后发现是SELinux的问题，临时关闭或者设置正确上下文才能解决。
还有一个版本选择上的建议：如果只是学习，装4.4或者6.0都行；如果是装Ops Manager这类监控管理工具，那必须卡死对应的版本要求。热搜词里出现"安装mongodb ops manager4.4"，说明不少人正在用4.4版本搭建Ops Manager。Ops Manager本质上是MongoDB官方提供的可视化运维平台，它本身也依赖一个MongoDB实例来存配置数据。装它之前先确认目标MongoDB版本是4.4.x，否则后续会出现兼容性报错。
2.2 Windows环境安装与绿色版小技巧
Windows下安装MongoDB其实更简单，官方提供了MSI安装包，一路点Next就行。但需要注意两个选择：一是安装时把"Install MongoDB Compass"勾上，虽然Compass后面也可以单独装，但一次性搞定省事；二是安装路径尽量别带空格和中文，之前有人在C:\Program Files下装完，配置文件的路径解析各种反人类。
Windows安装完默认是注册成Windows服务的，服务名是MongoDB，启动方式直接net start MongoDB。但是我自己实测下来，更推荐用"绿色版"的方式：直接下载zip解压包，解压到一个目录，比如D:\mongodb4.4，然后在目录下建好data\db和data\log两个文件夹，启动时用命令行：
mongod --dbpath D:\mongodb4.4\data\db --logpath D:\mongodb4.4\data\log\mongod.log这种方式的好处是随时可以启动多个不同版本的实例，测试时切换版本只需要换一个解压目录就够了。很多"mongodb安装失败"的问题其实是服务方式安装时权限或路径出问题，用绿色版基本能绕开这些坑。
2.3 启动失败与fassert()报错的真相
安装过程中最让人崩溃的错误之一，是日志里出现fassert()相关的字样。搜"mongodb fassert()"的帖子特别多，这里我说明一下：fassert()是MongoDB源码里的一个断言函数，当进程内部检测到致命状态时会调用它终止进程，所以看到Fatal Assertion或者fassert，说明MongoDB主动"自杀"了，而不是系统崩溃。
最常见的触发场景有两个。一个是存储引擎的wiredTiger元数据损坏，多数是上次非正常关机导致的，日志里会出现类似WiredTiger (13) Permission denied或者Operation not permitted的行。另一个是版本不兼容，比如数据文件是由更高版本的MongoDB创建的，低版本启动时也会触发断言。
遇到这种问题别慌，先确认三条信息：当前用的MongoDB版本、数据目录里dbpath的完整路径是否可写、上次关闭是否正常。如果确认是异常关机导致的，备份好整个data/db目录后，可以尝试用mongod --repair来修复，注意修复必须在数据文件版本对应的MongoDB版本下进行，否则越修越坏。实在不行，直接换一个干净的数据目录重新初始化，这是最快但也是最后的手段。
3. 数据库基本操作：增删改查一次讲透
3.1 连接、建库、建集合的本质
MongoDB不需要手动创建数据库。输入use testdb，表面上只是切换到了一个叫testdb的上下文，实际上只有当你在里面写入第一条数据时，这个数据库才会真正被创建出来。这个延迟创建的机制让许多新手误以为"我没有建库"。同理，集合也不需要预先创建，db.test.insertOne({...})执行完，test集合就自动出现了。
连接方式上，最简单的就是启动mongo客户端然后直接回车，默认连接localhost的27017端口。指定主机和端口可以这样：
mongo 192.168.1.10:27017/mydb -u username -p password --authenticationDatabase admin这里提一个细节：-u和-p后面如果带数据库名，是指定要操作的库；如果没带，MongoDB会先从admin库做认证。很多"MongoDB连接不上""认证失败"的问题，都是因为指定的认证库不对。
查看当前数据库使用db命令，列出所有数据库用show dbs，查看当前库所有集合用show collections。其中show dbs有个特点：刚插入数据但内存还没落盘的数据库可能不显示，需要等一会儿或者触发一次db.fsyncLock()这类强制刷盘操作。但实际开发中很少用到后者，知道有这回事就行。
3.2 插入与查询入门
插入操作优先推荐insertOne和insertMany两个方法。回到"头歌MongoDB数据库基本操作"这类题目，其实考的就是这两个方法的正确调用，以及后面要讲的find。
db.users.insertOne({ name: "zhang", age: 28, city: "shanghai", tags: ["java", "python"] }) db.users.insertMany([ { name: "li", age: 22, city: "beijing", tags: ["go"] }, { name: "wang", age: 30, city: "shanghai", tags: ["java", "mongo"] } ])查询最基本的方法是find()，它返回一个游标对象。很多人直接敲db.users.find()发现结果一屏装不下，就开始慌，其实加个.pretty()就能格式化显示。如果只想看一条，用findOne()。
条件查询直接用JSON对象表示。比如查城市是上海的用户：
db.users.find({ city: "shanghai" }).pretty()查询年龄大于25的：
db.users.find({ age: { $gt: 25 } })这里$gt是MongoDB查询操作符，对应大于。类似的还有$lt小于、$gte大于等于、$lte小于等于、$ne不等于、$in在列表内、$nin不在列表内。这些操作符是后续一切复杂查询的积木，必须记熟。
3.3 更新与删除的细节
更新操作是重灾区。新手最容易犯的错误是只用update不带任何更新操作符，把整个文档替换掉，比如把{name: "zhang", age: 28, city: "shanghai"}直接更新成{name: "zhang", age: 29}，结果city和tags全没了。正确的做法是使用$set操作符只更新指定字段：
db.users.updateOne( { name: "zhang" }, { $set: { age: 29 } } )updateOne只更新匹配到的第一条，updateMany更新所有匹配到的文档。如果需要"有则更新，无则插入"，用upsert: true选项：
db.users.updateOne( { name: "zhao" }, { $set: { age: 26, city: "guangzhou" } }, { upsert: true } )删除操作同样分deleteOne和deleteMany。注意db.users.remove({})这种旧写法能清空整个集合，但现在已经不推荐了，而且如果集合极大，remove会非常慢。清空整个集合正确的方式是db.users.deleteMany({})，想彻底释放存储空间则用db.users.drop()直接删掉集合。
4. 查询语句进阶：嵌套list到底怎么查
4.1 比较、逻辑与正则操作符组合出招
项目中真正用得多的，是多个操作符组装在一起的复合查询。比如查"年龄在20到30之间，且城市是上海或北京的Java开发者"：
db.users.find({ age: { $gte: 20, $lte: 30 }, city: { $in: ["shanghai", "beijing"] }, tags: "java" }).pretty()这里tags: "java"这种写法，如果tags字段是一个数组，MongoDB会自动匹配数组里包含"java"的文档，这就是数组字段的默认查询行为，不需要额外使用$elemMatch。很多人一开始不知道这一点，以为数组查询必须特殊处理，其实普通相等匹配就能覆盖大部分场景。
逻辑操作符$and、$or、$not、$nor则负责组合多个条件。比如查"年龄小于20，或者城市是上海且年龄小于35"：
db.users.find({ $or: [ { age: { $lt: 20 } }, { city: "shanghai", age: { $lt: 35 } } ] })正则查询用$regex，比如查所有名字以"zh"开头的用户：
db.users.find({ name: { $regex: "^zh" } })实际开发中，正则查询通常和索引配合使用，否则全表扫描很慢。前缀正则^zh恰好能用普通索引优化，但如果正则写成zh$结尾匹配，索引就失效了。知道这个区别，能帮你写出性能更稳的查询。
4.2 嵌套文档与嵌套数组的查询方法
"mongodb怎么查list嵌套list"是热搜词里很有代表性的一类问题。先看一个典型的嵌套数组场景，每个用户的文档里有一个orders字段，里面放多笔订单，每笔订单又是一个数组或者嵌套对象：
db.users.insertOne({ name: "zhang", orders: [ { id: 1001, items: [{ sku: "a", price: 10 }, { sku: "b", price: 20 }] }, { id: 1002, items: [{ sku: "c", price: 30 }] } ] })要查"orders里包含id为1001订单的用户"，直接用点号路径就行：
db.users.find({ "orders.id": 1001 })注意点号路径的字段名必须加引号，不能写成orders.id不带引号，字符串里带引号是正确姿势。这里orders是数组，MongoDB会扫描数组里的每一个元素，看元素的id字段是否等于1001，这是数组内嵌文档的默认匹配行为。
如果你要查"至少有一笔订单里items存在price大于20的商品"，光靠点号路径不行，因为会导致数组元素之间字段错位匹配的问题。必须用$elemMatch：
db.users.find({ orders: { $elemMatch: { "items.price": { $gt: 20 } } } })$elemMatch要求整个内部的匹配逻辑必须落在同一个数组元素上，这是嵌套list查询里最重要的一个操作符。很多"查嵌套list嵌套list"的问题，归根结底就是没用对$elemMatch，结果查出来的数据要么漏了，要么多了。
4.3 用$unwind展开嵌套数组后再查
还有一种思路，遇到多层嵌套又怕匹配逻辑复杂，可以先把嵌套数组用$unwind展开成一个个独立的临时文档，再结合$match查询。例如：
db.users.aggregate([ { $unwind: "$orders" }, { $unwind: "$orders.items" }, { $match: { "orders.items.price": { $gt: 20 } } }, { $project: { name: 1, orders: 1 } } ])这段管道的效果是：先把每个用户的orders数组逐条展开，再把每笔订单的items逐条展开，之后$match只保留符合条件的行。这个写法在调试阶段尤其好用，因为你能直观地看到展开之后每一行的结构，不会像$elemMatch那样有"到底匹配没匹配"的困惑。
要注意的是$unwind展开后一个用户会变成多行，后续如果要做去重统计，可以再用$group按_id收拢回来。这个是聚合操作的范围了，正好引出下一节。
5. 聚合函数查询统计：group by和解
5.1 聚合管道的核心概念
MongoDB的聚合框架大致对应SQL里的GROUP BY、HAVING、ORDER BY、LIMIT，但执行方式完全不同。它不是一条语句搞定，而是把一堆操作串成管道，前一个操作的结果继续喂给后一个操作去处理。"mongodb之聚合函数查询统计"这类学习任务，本质就是让你把这张管道图理顺。
管道里的每个阶段用一个JSON对象表示。最常用的四个节点是：$match负责过滤，$group负责分组统计，$project负责字段重塑，$sort负责排序。把这些节点串起来，就完成了一段聚合查询。
要理解聚合，最直观的方式是从一个"按城市统计用户数量和平均年龄"的需求入手：
db.users.aggregate([ { $match: { age: { $gt: 20 } } }, { $group: { _id: "$city", count: { $sum: 1 }, avgAge: { $avg: "$age" } } }, { $sort: { count: -1 } } ])这段的含义是：先只保留年龄大于20的用户，然后按city分组，$sum: 1表示每出现一个文档计数加1，$avg: "$age"表示求组内age字段的平均值。注意字段名前带$符号，用来表示引用文档里的字段。如果漏了$，MongoDB会把"city"当成字符串常量，结果全部分成同一组，这是最常见的聚合翻车点。
5.2 $group、$sum、$avg、$match组合实战
在$group节点里，_id是必须指定的分组键，其他字段都是统计结果。_id可以是单字段，也可以是一个嵌套对象，实现多字段分组。比如统计"每个城市里每个年龄段的人数"：
db.users.aggregate([ { $group: { _id: { city: "$city", ageGroup: "$age" }, count: { $sum: 1 } } } ])这个查询会把城市和年龄完全相同的用户归为一组。分组键是复合结构时，结果中的_id也会变成一个子文档。
$sum: 1之外，还可以用$sum: "$price"实现对字段值的累加。比如统计每个用户订单总金额：
db.users.aggregate([ { $unwind: "$orders" }, { $group: { _id: "$name", total: { $sum: "$orders.price" } } } ])这里如果orders的每个元素有price字段，先unwind把每个订单变成独立文档，再按name分组求和。注意如果订单嵌套更深，比如price在orders.items.price里，就需要先两次unwind再在分组前用$sum配合$multiply等方法处理。
$match放在聚合开头和放在中间效果不一样。放在开头可以提前过滤掉大量不相关的文档，节省后面阶段的开销，类似SQL中WHERE优先执行的优化思路；放在中间则可以过滤掉某些分组计算后的中间结果，比如只保留总数大于5的城市，这种功能类似SQL里的HAVING，但实现方式更灵活。
5.3 用$project重塑输出结果
聚合查出来的结果往往有不少中间字段，直接输出比较乱。$project节点专门负责"选择输出哪些字段，以及怎么加工"。比如上面的复合分组结果想输出成城市、年龄段、人数三个平铺字段：
db.users.aggregate([ { $group: { _id: { city: "$city", ageGroup: "$age" }, count: { $sum: 1 } } }, { $project: { _id: 0, city: "$_id.city", ageGroup: "$_id.ageGroup", count: 1 } }, { $sort: { count: -1 } } ])_id: 0表示不输出_id字段，city: "$_id.city"表示从嵌套的_id对象里取city字段重新赋值给结果里的city。count: 1表示原样保留。这套字段重塑的逻辑和JSON对象操作很像，一旦理解了，复杂的聚合结果想怎么展示就怎么展示。
6. 数据库安全配置：从裸奔到及格
6.1 开启认证的完整过程
很多教程在你第一次启动MongoDB时根本没提安全这回事，导致默认安装完就是一个没有任何认证的实例，谁连上27017端口，谁就能读写全部数据。这在公司内网还好说，一旦端口映射到公网，基本等于裸奔。网上搜到"mongodb数据库安全"相关题目，核心诉求就是让你学会开启访问控制和认证。
先看现在常见做法。启动MongoDB后，先连上admin库创建一个管理员用户：
use admin db.createUser({ user: "root", pwd: "your_strong_password", roles: [ { role: "root", db: "admin" } ] })这里root角色是MongoDB里的超级管理员，能管理所有库。创建完用户后，修改MongoDB配置文件/etc/mongod.conf，添加或修改security段：
security: authorization: enabled然后重启mongod：
systemctl restart mongod重启后，再执行mongo直接回车就会连不上，并提示需要认证，这是正常的。必须通过mongo -u root -p your_strong_password --authenticationDatabase admin才能进入。这个"认证库"的概念非常关键，用户是在哪个库下面创建的，连接时就必须指定那个库做认证。
如果你已经创建了用户才发现没有开启认证，也不需要删数据重建。只要按上面步骤创建用户、改配置、重启，就能平滑开启访问控制。实测下来这个流程是最稳妥的，不会出现"开启认证后原有数据不可访问"的情况。
6.2 角色权限设计要点
实际项目中不太建议所有应用都用一个root账号。MongoDB的角色体系把权限分得很细，比如read只允许读，readWrite允许读写，dbAdmin负责管理索引和集合，clusterAdmin管集群层面。最小权限原则在这里同样适用：一个业务服务只需要读写某个库，就单独创建一个绑定该库的用户：
use myapp db.createUser({ user: "app_user", pwd: "app_password", roles: [ { role: "readWrite", db: "myapp" } ] })这里特别注意，创建这个用户时所在的use库，和roles里面db字段指定的库，两者可能不一样。认证时MongoDB去myapp库里找用户信息，这也是新手经常搞混的地方。如果创建时没有指定db，默认使用当前use的库，之后连接时认证库就要填一样的库名。
安全配置做到及格线，至少应该包括：开启authorization: enabled，禁用或者关闭bindIp对外网开放，给所有库的业务账号分配最小角色，定期备份。如果公司要求更高，还可以上企业版的字段级加密或者搭配Ops Manager做自动备份和监控，但那些都是后话。
6.3 头歌安全类练习题的答题思路
平台上那些"MongoDB数据库安全"的练习，出题套路比较固定：先创建一个有权限的用户，然后让你在未认证和已认证两种状态下分别验证能否读写，最后判断授权是否正确。这类题本质上是检验你对db.createUser、roles、--authenticationDatabase这几个知识点的掌握程度。
我建议做这类练习时，别急着背命令，把流程自己完整走一遍：先创建用户，再重启服务，再用新用户连接，最后尝试跨库访问一个没有权限的库，看看是否被拒。亲手验证过一遍权限模型，比刷十道题都管用。做题时如果某一步连接失败，优先检查认证库是否写对，八成的问题都出在这里。
7. 常见问题排查实录
7.1 安装失败的高频原因与对策
mongodb安装失败这个热搜词下面，我能想到的典型原因大概五类。第一，yum源里没有对应版本，多半是baseurl里$releasever解析出的系统版本和官方源不匹配，解决办法是手动改成7.0之类的固定值。第二，依赖包冲突，安装时报libcrypto.so.10这类找不到库的错误，多数是老系统需要更新openssl或libssl版本。第三，磁盘空间不足，但日志提示不明显，检查一下/var/lib/mongodb所在分区的剩余空间。第四，SELinux拦截，前面已经提过。第五，端口被占用，27017端口已经被别的进程占着，启动就会报address already in use。
排查顺序我建议是：先看日志，再看端口，再看磁盘，最后考虑源的问题。MongoDB的日志一般写在/var/log/mongodb/mongod.log，用tail -100拉出最后一百行，大多数错误原因都能直接看到。
7.2 连接失败、认证失败与超时的区分
连接失败和认证失败是两个完全不同的问题，但新手经常混在一起。连接失败是根本到不了MongoDB，表现为connect timed out或者connection refused；认证失败是连上了但要密码时密码不对，表现为Authentication failed。定位思路也不同：连接失败先查网络，用telnet 192.168.1.10 27017测试端口通不通；认证失败先查用户名、密码和认证库。
还有一类情况是连接超时，原因可能是机器负载太高、网络丢包、或者MongoDB开启了/etc/hosts解析异常。我的经验是，连接超时优先看服务器CPU和负载，尤其是有慢查询在跑的时候，MongoDB可能连握手都顾不上。如果CPU不高但依然超时，再检查防火墙和云安全组规则。
7.3 聚合查询慢或内存爆掉的处理心得
聚合管道跑起来慢，通常有两种情况。一种是没有充分利用索引，最常见是$match过滤条件没有落到索引上，导致全表扫描。做法是先用db.collection.createIndex()给过滤字段建好索引，再在管道里把$match尽量放前面。另一种是$unwind展开后数据膨胀太厉害，展开了几百万行，后面的$group内存根本顶不住。
MongoDB聚合默认有100MB的内存限制，超过了会报错。解决办法有两种：一是加allowDiskUse: true允许使用磁盘临时文件，比如：
db.users.aggregate([...], { allowDiskUse: true })二是从业务上拆分，先缩小数据范围再做聚合。我的建议是优先做业务拆分，磁盘排序带来的性能损耗在数据量大时非常明显，能避免就避免。
还有个小技巧：聚合结果如果只需要一部分字段，不要把整条文档都推给后面的阶段处理，在$project或者$match阶段就把不需要的字段扔掉，能显著减轻后续阶段的压力。这也是"mongodb之聚合函数查询统计"里经常考到的优化点。
8. 最后分享几个实战中的小习惯
个人经验是，MongoDB学习曲线最陡的地方不在语法，而在思维转换。SQL里你习惯了一堆表join一起查，MongoDB里你更倾向于把相关联的数据直接嵌套在同一个文档里。嵌套越深，查询越灵活，但更新代价也越大。实际项目里，文档设计得不好，后面查询和聚合全都跟着遭殃。
我给自己定的几条规矩：集合里的文档结构尽量保持稳定，即使字段允许不一致，也别真的让它五花八门；所有查询条件涉及的字段，尤其在集群环境里，一定要建索引；能用updateOne就别用update，能写$set就绝不整文档替换。每次踩完坑我都把原因记下来，后来发现80%的问题都是同一个套路：要么没用索引，要么嵌套太深还硬用点号路径查。
如果你现在正卡在某个"mongodb安装失败"或者"查询嵌套list"的问题上，先按照上面第2节和第4节的方法走一遍，大概率能解决。实在不行，把报错信息里最关键的一行贴到搜索引擎里，比瞎改配置有效率得多。MongoDB的生态已经很成熟，官方文档也写得很详细，多动手验证几次，比背多少篇教程都强。