1. 为什么命令行才是 MongoDB 的真正入口很多人第一次接触 MongoDB 都是通过图形化工具点几下鼠标就能建库建表、增删改查感觉挺方便。但真到了线上环境尤其是服务器没有图形界面、只能通过终端连接的时候命令行就成了唯一的选择。我见过不少开发者平时用图形工具用得飞起一上服务器就懵了连怎么切库、怎么查集合大小都要现搜这就很被动了。MongoDB 的命令行工具叫mongosh它是官方推出的新一代 Shell替代了老版本的mongo命令。两者在基础操作上大同小异但mongosh支持更现代的 JavaScript 语法、更好的自动补全和语法高亮如果你现在还在用老版的mongo建议尽快切过来。这篇文章我会围绕mongosh展开把日常运维和开发中最常用的命令梳理一遍同时把每个命令背后的逻辑和容易踩的坑讲清楚。这篇文章适合谁看如果你是刚接触 MongoDB 的后端开发者或者需要经常上服务器排查问题的运维人员再或者你平时用图形工具但想补一补命令行基本功那这篇内容应该能帮到你。我不会只列一堆命令让你背而是按照实际工作场景来组织告诉你什么情况下该用什么命令参数为什么这么设以及我这些年踩过的那些坑。2. 连接与基础环境操作2.1 连接数据库的几种姿势连接 MongoDB 是所有操作的第一步。最基本的连接方式就是直接敲mongosh它会默认连接到本地的27017端口。但实际工作中我们更多是连接远程服务器这时候就需要指定主机和端口mongosh mongodb://username:passwordhost:port/database这里有几个细节值得注意。第一如果你的密码里包含、:、/这些特殊字符一定要做 URL 编码否则连接字符串会被解析错。我就遇到过密码里有符号导致一直连不上的情况排查了半天才发现是编码问题。第二连接字符串末尾的/database是可选的如果不指定连接后会默认落在test库这个库在生产环境通常是不存在的容易让人困惑。如果你不想把密码明文写在命令里毕竟会留在历史记录中可以用--username和--password参数执行后会提示你交互式输入密码mongosh --host 192.168.1.100 --port 27017 --username admin --authenticationDatabase admin这里要特别说一下--authenticationDatabase这个参数。MongoDB 的用户是挂在某个数据库下的认证的时候需要知道去哪个库验证。很多新手连接不上就是因为没指定这个参数默认去了目标库认证结果用户其实建在admin库里。一般来说管理员用户都建在admin库普通业务用户建在对应的业务库里。还有一种场景是连接副本集。副本集的连接字符串需要列出所有节点并指定replicaSet参数mongosh mongodb://host1:27017,host2:27017,host3:27017/mydb?replicaSetrs0这样驱动会自动发现主节点读写请求会路由到正确的地方。如果你只连了其中一个节点而那个节点恰好是从节点默认是不允许写入的会报not master的错误。2.2 库与集合的日常操作连上之后第一件事通常是看看有哪些库。show dbs是最常用的命令但它有个特点只显示有数据的库。如果你刚建了一个空库show dbs是看不到的因为 MongoDB 的库是懒创建的只有往里面写入第一条数据时才会真正落盘。这一点和 MySQL 那种先CREATE DATABASE再用的模式不太一样新手容易在这里犯迷糊。切换库用use命令use myapp如果这个库不存在use也不会报错而是标记为当前库等你真正写入数据时才创建。查看当前在哪个库可以用db命令它会返回当前库的名字。查看当前库下有哪些集合用show collections。删除集合用db.collectionName.drop()删除整个库用db.dropDatabase()。这两个操作都是不可逆的执行前一定要确认清楚。我个人的习惯是在生产环境执行任何drop操作前先show collections或db.stats()确认一下当前库的身份避免因为连错环境而误删。查看库的统计信息用db.stats()它会返回集合数量、文档总数、数据大小、存储大小、索引大小等关键指标。这个命令在排查磁盘占用问题时特别有用。比如你发现磁盘快满了想知道是哪个库占的空间就可以逐个库执行db.stats()对比。db.stats()返回结果里有个storageSize和dataSize的区别值得说一下。dataSize是逻辑数据大小storageSize是实际占用的磁盘空间。通常storageSize会大于dataSize因为 MongoDB 的存储引擎WiredTiger会有压缩和预分配。但如果两者差距特别大可能说明有大量删除操作留下的碎片需要考虑做压缩整理。3. 查询与数据操作的核心命令3.1 查询文档的常用写法查询是日常用得最多的操作。最基本的find命令db.users.find({ age: { $gt: 18 } })这条命令会返回所有年龄大于 18 的文档。但默认情况下find只返回前 20 条如果数据多需要输入it命令继续翻页。这个交互方式在终端里还行但如果是脚本里用就要注意用toArray()或者游标遍历。条件操作符是查询的核心常用的有操作符含义示例$gt大于{ age: { $gt: 18 } }$gte大于等于{ age: { $gte: 18 } }$lt小于{ age: { $lt: 60 } }$in在数组中{ status: { $in: [active, pending] } }$ne不等于{ status: { $ne: deleted } }$exists字段是否存在{ email: { $exists: true } }组合条件用$and、$or、$nor。比如要查年龄在 18 到 60 之间、且状态为 active 的用户db.users.find({ $and: [ { age: { $gte: 18, $lte: 60 } }, { status: active } ] })其实同一个字段上的多个条件可以直接写在一起像{ age: { $gte: 18, $lte: 60 } }这样MongoDB 会自动做 AND 处理。只有跨字段的 OR 条件才必须用$or。投影是查询中经常被忽略但很重要的部分。默认find返回文档的所有字段如果文档很大网络传输和内存开销都会增加。用投影只返回需要的字段db.users.find({ status: active }, { name: 1, email: 1, _id: 0 })这里1表示包含该字段0表示排除。注意_id字段默认是包含的如果不想返回要显式设为0。另外包含和排除不能混用除了_id比如你不能写{ name: 1, email: 0 }这会报错。排序用sort分页用skip和limitdb.users.find().sort({ createdAt: -1 }).skip(20).limit(10)-1表示降序1表示升序。这里有个性能陷阱skip在数据量大时非常慢因为 MongoDB 要先扫描并丢弃前面 N 条记录。如果要做深度分页更好的方式是用范围查询比如记住上一页最后一条的createdAt下一页查{ createdAt: { $lt: lastCreatedAt } }。统计数量用countDocumentsdb.users.countDocuments({ status: active })老版本有count()方法但它在新版本中已经被标记为废弃因为它返回的是元数据估算值不准确。countDocuments会实际扫描并计数结果准确但慢一些。如果只是要个大概数量可以用estimatedDocumentCount()它直接读元数据非常快。3.2 插入、更新与删除的实操细节插入单条文档用insertOnedb.users.insertOne({ name: 张三, age: 28, status: active, createdAt: new Date() })插入多条用insertMany传入数组。这里有个细节insertMany默认是有序插入如果中间某条失败后面的不会继续。如果希望跳过失败继续插入可以加{ ordered: false }参数。更新操作是命令行的重头戏。updateOne更新第一条匹配的文档updateMany更新所有匹配的db.users.updateMany( { status: inactive }, { $set: { status: active, updatedAt: new Date() } } )更新操作符除了$set常用的还有$unset删除字段、$inc数值增减、$push数组追加、$pull数组移除。比如给所有用户年龄加一岁db.users.updateMany({}, { $inc: { age: 1 } })这里要特别提醒updateOne和updateMany如果不带更新操作符直接传一个文档会变成整体替换把原文档的其他字段全丢掉。比如db.users.updateOne({ name: 张三 }, { age: 30 })执行后张三的文档就只剩_id和age了name都没了。这个坑我踩过当时差点把生产数据搞坏。所以更新时一定要用$set这类操作符。删除用deleteOne和deleteManydb.users.deleteMany({ status: deleted })删除前建议先用同样的条件find一下确认要删的数据范围。我个人的习惯是执行deleteMany前先把条件改成find跑一遍看看数量对不对再换成deleteMany。3.3 聚合管道的实战应用聚合是 MongoDB 最强大的功能之一aggregate命令可以完成分组、统计、关联查询等复杂操作。基本结构是管道式的每个阶段处理完的数据传给下一个阶段db.orders.aggregate([ { $match: { status: completed } }, { $group: { _id: $userId, total: { $sum: $amount } } }, { $sort: { total: -1 } }, { $limit: 10 } ])这个例子是统计消费金额最高的前 10 个用户。$match过滤已完成订单$group按用户分组求和$sort降序排列$limit取前 10。$lookup可以实现类似 SQL 的 JOINdb.orders.aggregate([ { $lookup: { from: users, localField: userId, foreignField: _id, as: userInfo } } ])不过$lookup的性能开销比较大尤其是数据量大时。如果频繁需要关联查询可能要考虑把数据冗余存储用空间换时间。聚合管道里还有一个常用的$project阶段用来重塑文档结构db.users.aggregate([ { $project: { name: 1, age: 1, ageGroup: { $cond: { if: { $gte: [$age, 18] }, then: adult, else: minor } } } } ])这里用$cond做了条件判断根据年龄生成一个新字段。聚合表达式的功能非常丰富支持字符串处理、日期运算、数组操作等值得单独花时间研究。4. 索引管理与性能排查4.1 索引的创建与查看索引是数据库性能的命脉。没有索引的查询叫全表扫描数据量一大就慢得没法看。查看集合现有索引用getIndexes()db.users.getIndexes()创建索引用createIndexdb.users.createIndex({ email: 1 }, { unique: true })1表示升序-1表示降序。对于单字段索引升降序无所谓但复合索引的字段顺序和方向会影响查询能否命中。复合索引遵循最左前缀原则比如{ a: 1, b: 1 }这个索引能支持a的查询和a b的查询但单独查b用不上这个索引。创建索引时加{ background: true }可以让索引在后台构建不阻塞其他操作。不过在新版本的 WiredTiger 引擎中前台和后台索引构建的差异已经不那么明显了但生产环境建大索引还是建议在低峰期操作。唯一索引可以保证字段值的唯一性但要注意如果集合中已有重复数据创建唯一索引会失败。这时候需要先清理重复数据或者用{ unique: true, sparse: true }只对存在该字段的文档做唯一约束。TTL 索引是个很实用的特性可以自动过期删除文档db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })这样createdAt超过 1 小时的文档会被自动删除非常适合会话管理、临时日志这类场景。不过 TTL 索引的清理是后台线程定期执行的不是精确到秒通常有几十秒到几分钟的延迟。4.2 用 explain 分析查询性能explain是排查慢查询的利器。加上executionStats参数可以看到详细的执行统计db.users.find({ email: testexample.com }).explain(executionStats)返回结果里要重点看几个指标executionStats.executionTimeMillis执行耗时单位毫秒executionStats.totalDocsExamined扫描的文档数executionStats.totalKeysExamined扫描的索引键数winningPlan.stage获胜的执行计划阶段理想情况下totalDocsExamined应该接近返回的文档数如果远大于返回数说明索引没用好。winningPlan.stage如果是COLLSCAN说明走了全表扫描需要加索引如果是IXSCAN说明用上了索引。我遇到过一种情况查询条件里用了$regex做模糊匹配结果一直走全表扫描。原因是正则表达式如果以^开头且不是大小写敏感模式MongoDB 才能用上索引。如果正则中间有通配符索引就无能为力了。这种场景要么改查询方式要么上全文索引。4.3 慢查询日志与性能监控MongoDB 有个慢查询日志功能可以记录超过指定阈值的操作。查看当前设置db.getProfilingStatus()设置慢查询阈值单位毫秒db.setProfilingLevel(1, { slowms: 100 })级别0是关闭1是只记录慢操作2是记录所有操作。生产环境一般用1阈值设 100 到 200 毫秒比较合适。设置后慢查询会记录在system.profile集合里可以这样查询db.system.profile.find({ millis: { $gt: 100 } }).sort({ ts: -1 }).limit(10)这个集合是固定大小的 capped collection满了会自动覆盖旧记录所以不用担心无限增长。但要注意开启 profiling 本身有性能开销排查完问题后建议关掉或调高阈值。除了慢查询日志db.currentOp()可以查看当前正在执行的操作db.currentOp({ secs_running: { $gt: 5 } })这个命令能看到运行超过 5 秒的操作包括操作类型、涉及的库和集合、执行时间等。如果发现有长时间运行的操作可以用db.killOp(opid)终止它。不过 kill 操作要谨慎尤其是写操作强行终止可能导致数据不一致。5. 数据导入导出与备份恢复5.1 用 mongoexport 和 mongoimport 处理数据mongoexport可以把集合导出成 JSON 或 CSV 格式mongoexport --db myapp --collection users --out users.json导出 CSV 需要指定字段mongoexport --db myapp --collection users --typecsv --fields name,email,age --out users.csv这里有个坑CSV 导出时如果字段值里包含逗号或换行需要做转义处理否则导入时会错位。JSON 格式没有这个问题但文件会大一些。如果数据量特别大建议加--limit分批导出避免单文件过大。mongoimport用于导入数据mongoimport --db myapp --collection users --file users.json导入 JSON 数组格式时要加--jsonArray参数否则 mongoimport 会按每行一个文档解析遇到数组格式就报错。这个细节很容易被忽略我第一次用的时候就卡在这里。5.2 mongodump 和 mongorestore 做备份恢复mongoexport导出的是数据内容不包含索引和集合选项。如果要完整备份应该用mongodumpmongodump --db myapp --out /backup/mongodb/它会导出 BSON 格式的数据文件和元数据 JSON恢复时用mongorestoremongorestore --db myapp /backup/mongodb/myapp/mongodump支持压缩输出加--gzip参数可以显著减小备份文件体积mongodump --db myapp --gzip --out /backup/mongodb/恢复时对应加--gzipmongorestore --gzip /backup/mongodb/备份策略上我一般建议至少保留最近 7 天的每日备份加上每周一次的完整备份。如果数据量特别大可以考虑增量备份但 MongoDB 的增量备份需要结合 oplog 来做复杂度较高一般中小规模直接用全量备份就够了。恢复的时候有个注意事项mongorestore默认是追加模式如果目标库已有同名集合会往里面插入数据而不是覆盖。如果要先删除再恢复加--drop参数。这个参数在生产环境要慎用确认清楚再执行。6. 用户权限与安全管理6.1 创建用户与分配角色MongoDB 的用户是挂在数据库下的创建用户时要先切到对应的库use admin db.createUser({ user: adminUser, pwd: strongPassword, roles: [ { role: userAdminAnyDatabase, db: admin }, { role: readWriteAnyDatabase, db: admin } ] })常用角色有这么几类角色权限范围read只读readWrite读写dbAdmin库管理索引、统计等userAdmin用户管理clusterAdmin集群管理root超级管理员生产环境一定要遵循最小权限原则业务应用只给readWrite不要图省事直接给root。我见过有团队所有服务都用管理员账号连数据库结果一个服务被攻破整个数据库都暴露了。修改用户密码用updateUserdb.changeUserPassword(username, newPassword)删除用户用dropUserdb.dropUser(username)查看当前库下所有用户用show users查看所有库的用户需要切到admin库执行db.system.users.find()。6.2 认证配置与安全建议MongoDB 默认是不开启认证的这意味着任何人只要能连上端口就能操作数据。生产环境必须开启认证在配置文件里加上security: authorization: enabled开启认证后连接时必须提供用户名密码。如果之前没建管理员用户就开启了认证会把自己锁在外面所以顺序一定是先建用户再开认证。除了认证还有几个安全加固点值得注意。第一绑定 IP只监听内网地址不要暴露在公网net: bindIp: 127.0.0.1,192.168.1.100第二修改默认端口虽然不能根本解决安全问题但能减少被扫描的概率。第三启用审计日志记录所有敏感操作方便事后追溯。7. 常见问题排查与避坑经验7.1 连接类问题速查连接问题是最常见的我整理了一个速查表现象可能原因排查方法Connection refused服务未启动或端口不对netstat -tlnp检查端口监听Authentication failed用户名密码错或认证库不对确认--authenticationDatabasenot master连到了从节点检查副本集状态连主节点timeout网络不通或防火墙拦截telnet host port测试连通性too many connections连接数超限调大maxIncomingConnections认证失败这个问题特别常见很多时候不是密码错而是认证库搞错了。比如用户在admin库创建但连接时没指定--authenticationDatabase adminMongoDB 会去目标库找这个用户自然找不到。7.2 性能类问题排查思路性能问题排查有个基本顺序先看慢查询日志再用 explain 分析具体查询然后检查索引是否合理最后看服务器资源CPU、内存、磁盘 IO。一个典型的场景是某个查询突然变慢。排查步骤是先用db.currentOp()看有没有长时间运行的操作如果有看看它在干什么如果没有去system.profile里找最近的慢查询用 explain 分析执行计划。十有八九是索引问题要么没建索引要么索引被其他查询挤掉了。内存问题也值得关注。MongoDB 的 WiredTiger 引擎会用大量内存做缓存如果db.serverStatus().mem显示resident接近物理内存上限而virtual很大这是正常的。但如果出现频繁的 page fault说明内存不够需要考虑加内存或优化查询减少扫描量。7.3 我踩过的那些坑第一个坑是skip分页。早期做分页功能时用了skip limit数据量小的时候没问题数据上了百万级后翻到后面几页直接超时。后来改成基于游标的分页用上一页最后一条记录的_id或时间戳做条件性能立刻上来了。第二个坑是数组字段的索引。有次给一个数组字段建了普通索引查询时发现用不上。后来才知道数组字段要用多键索引multikey indexMongoDB 会自动识别数组并创建多键索引但复合索引里如果包含数组字段一个复合索引只能有一个数组字段多了会报错。第三个坑是$in查询的性能。$in里的值如果太多比如上千个查询会变得很慢因为 MongoDB 要逐个匹配。这种场景更好的做法是建一个临时集合把值导入进去然后用$lookup关联查询。第四个坑是更新时的类型变化。MongoDB 是模式灵活的同一个字段在不同文档里可以是不同类型。有次更新时不小心把数字字段更新成了字符串导致后续的数值比较查询全部失效。后来养成了习惯更新前先find看看字段类型用$type操作符确认。7.4 日常运维的实用技巧分享几个我日常用得比较多的技巧。第一个是用db.collection.stats()看集合的详细统计包括平均文档大小、索引大小、压缩比等。如果发现平均文档大小异常大可能有超大字段需要拆分。第二个是用db.collection.validate()检查集合完整性。这个命令会扫描集合和索引确认没有损坏。数据量大的时候会很慢建议在低峰期执行。第三个是用db.fsyncLock()和db.fsyncUnlock()做文件系统级别的备份。执行fsyncLock后MongoDB 会停止写入并把数据刷到磁盘这时候可以安全地复制数据文件。备份完记得fsyncUnlock否则数据库会一直处于锁定状态。第四个是db.setLogLevel()动态调整日志级别。排查问题时临时调高日志级别能看到更详细的信息排查完再调回去。不过日志级别调太高会产生大量日志注意磁盘空间。8. 命令行效率提升的进阶玩法8.1 自定义函数与脚本化mongosh支持 JavaScript可以定义自定义函数来简化重复操作。比如我经常需要按条件统计数量就定义了一个function countBy(collection, query) { return db.getCollection(collection).countDocuments(query) }定义后就可以直接countBy(users, { status: active })调用。这些函数在会话结束后就没了如果想持久化可以写到一个.js文件里启动时用--file参数加载mongosh --file /path/to/helpers.js更进阶的玩法是把常用操作写成脚本用mongosh直接执行mongosh mongodb://localhost:27017/myapp --eval db.users.countDocuments()--eval参数可以直接执行一段 JavaScript 并输出结果非常适合做定时任务或监控脚本。8.2 批量操作与循环处理有时候需要对多个集合执行相同操作可以用循环db.getCollectionNames().forEach(function(name) { var stats db.getCollection(name).stats() print(name : stats.count docs, stats.storageSize bytes) })这段脚本会遍历当前库所有集合打印文档数和存储大小。类似的思路可以用在批量建索引、批量清理数据等场景。批量更新时如果数据量特别大建议分批处理避免单次操作锁太久var batchSize 1000 var processed 0 while (true) { var docs db.users.find({ status: pending }).limit(batchSize).toArray() if (docs.length 0) break docs.forEach(function(doc) { db.users.updateOne({ _id: doc._id }, { $set: { status: processed } }) }) processed docs.length print(Processed: processed) }这种分批处理的方式虽然慢一些但对线上服务的影响小不会造成长时间的锁等待。8.3 监控脚本的编写思路最后分享一个简单的监控脚本思路。定期检查数据库的关键指标超过阈值就告警var stats db.stats() var connections db.serverStatus().connections print(Data Size: (stats.dataSize / 1024 / 1024).toFixed(2) MB) print(Storage Size: (stats.storageSize / 1024 / 1024).toFixed(2) MB) print(Index Size: (stats.indexSize / 1024 / 1024).toFixed(2) MB) print(Current Connections: connections.current) print(Available Connections: connections.available) if (connections.current / (connections.current connections.available) 0.8) { print(WARNING: Connection usage over 80%) }这个脚本可以配合系统的定时任务每小时跑一次输出重定向到日志文件再用日志分析工具做告警。虽然比不上专业的监控系统但在资源有限的情况下这种轻量级方案也能解决不少问题。我在实际使用中最大的体会是命令行的熟练程度直接决定了排查问题的速度。图形工具虽然直观但遇到复杂查询和性能分析时还是命令行更灵活、更高效。建议大家在日常开发中就多用命令行把常用命令练成肌肉记忆真到了紧急排查的时候才能不慌。
1. 为什么命令行才是 MongoDB 的真正入口很多人第一次接触 MongoDB 都是通过图形化工具点几下鼠标就能建库建表、增删改查感觉挺方便。但真到了线上环境尤其是服务器没有图形界面、只能通过终端连接的时候命令行就成了唯一的选择。我见过不少开发者平时用图形工具用得飞起一上服务器就懵了连怎么切库、怎么查集合大小都要现搜这就很被动了。MongoDB 的命令行工具叫mongosh它是官方推出的新一代 Shell替代了老版本的mongo命令。两者在基础操作上大同小异但mongosh支持更现代的 JavaScript 语法、更好的自动补全和语法高亮如果你现在还在用老版的mongo建议尽快切过来。这篇文章我会围绕mongosh展开把日常运维和开发中最常用的命令梳理一遍同时把每个命令背后的逻辑和容易踩的坑讲清楚。这篇文章适合谁看如果你是刚接触 MongoDB 的后端开发者或者需要经常上服务器排查问题的运维人员再或者你平时用图形工具但想补一补命令行基本功那这篇内容应该能帮到你。我不会只列一堆命令让你背而是按照实际工作场景来组织告诉你什么情况下该用什么命令参数为什么这么设以及我这些年踩过的那些坑。2. 连接与基础环境操作2.1 连接数据库的几种姿势连接 MongoDB 是所有操作的第一步。最基本的连接方式就是直接敲mongosh它会默认连接到本地的27017端口。但实际工作中我们更多是连接远程服务器这时候就需要指定主机和端口mongosh mongodb://username:passwordhost:port/database这里有几个细节值得注意。第一如果你的密码里包含、:、/这些特殊字符一定要做 URL 编码否则连接字符串会被解析错。我就遇到过密码里有符号导致一直连不上的情况排查了半天才发现是编码问题。第二连接字符串末尾的/database是可选的如果不指定连接后会默认落在test库这个库在生产环境通常是不存在的容易让人困惑。如果你不想把密码明文写在命令里毕竟会留在历史记录中可以用--username和--password参数执行后会提示你交互式输入密码mongosh --host 192.168.1.100 --port 27017 --username admin --authenticationDatabase admin这里要特别说一下--authenticationDatabase这个参数。MongoDB 的用户是挂在某个数据库下的认证的时候需要知道去哪个库验证。很多新手连接不上就是因为没指定这个参数默认去了目标库认证结果用户其实建在admin库里。一般来说管理员用户都建在admin库普通业务用户建在对应的业务库里。还有一种场景是连接副本集。副本集的连接字符串需要列出所有节点并指定replicaSet参数mongosh mongodb://host1:27017,host2:27017,host3:27017/mydb?replicaSetrs0这样驱动会自动发现主节点读写请求会路由到正确的地方。如果你只连了其中一个节点而那个节点恰好是从节点默认是不允许写入的会报not master的错误。2.2 库与集合的日常操作连上之后第一件事通常是看看有哪些库。show dbs是最常用的命令但它有个特点只显示有数据的库。如果你刚建了一个空库show dbs是看不到的因为 MongoDB 的库是懒创建的只有往里面写入第一条数据时才会真正落盘。这一点和 MySQL 那种先CREATE DATABASE再用的模式不太一样新手容易在这里犯迷糊。切换库用use命令use myapp如果这个库不存在use也不会报错而是标记为当前库等你真正写入数据时才创建。查看当前在哪个库可以用db命令它会返回当前库的名字。查看当前库下有哪些集合用show collections。删除集合用db.collectionName.drop()删除整个库用db.dropDatabase()。这两个操作都是不可逆的执行前一定要确认清楚。我个人的习惯是在生产环境执行任何drop操作前先show collections或db.stats()确认一下当前库的身份避免因为连错环境而误删。查看库的统计信息用db.stats()它会返回集合数量、文档总数、数据大小、存储大小、索引大小等关键指标。这个命令在排查磁盘占用问题时特别有用。比如你发现磁盘快满了想知道是哪个库占的空间就可以逐个库执行db.stats()对比。db.stats()返回结果里有个storageSize和dataSize的区别值得说一下。dataSize是逻辑数据大小storageSize是实际占用的磁盘空间。通常storageSize会大于dataSize因为 MongoDB 的存储引擎WiredTiger会有压缩和预分配。但如果两者差距特别大可能说明有大量删除操作留下的碎片需要考虑做压缩整理。3. 查询与数据操作的核心命令3.1 查询文档的常用写法查询是日常用得最多的操作。最基本的find命令db.users.find({ age: { $gt: 18 } })这条命令会返回所有年龄大于 18 的文档。但默认情况下find只返回前 20 条如果数据多需要输入it命令继续翻页。这个交互方式在终端里还行但如果是脚本里用就要注意用toArray()或者游标遍历。条件操作符是查询的核心常用的有操作符含义示例$gt大于{ age: { $gt: 18 } }$gte大于等于{ age: { $gte: 18 } }$lt小于{ age: { $lt: 60 } }$in在数组中{ status: { $in: [active, pending] } }$ne不等于{ status: { $ne: deleted } }$exists字段是否存在{ email: { $exists: true } }组合条件用$and、$or、$nor。比如要查年龄在 18 到 60 之间、且状态为 active 的用户db.users.find({ $and: [ { age: { $gte: 18, $lte: 60 } }, { status: active } ] })其实同一个字段上的多个条件可以直接写在一起像{ age: { $gte: 18, $lte: 60 } }这样MongoDB 会自动做 AND 处理。只有跨字段的 OR 条件才必须用$or。投影是查询中经常被忽略但很重要的部分。默认find返回文档的所有字段如果文档很大网络传输和内存开销都会增加。用投影只返回需要的字段db.users.find({ status: active }, { name: 1, email: 1, _id: 0 })这里1表示包含该字段0表示排除。注意_id字段默认是包含的如果不想返回要显式设为0。另外包含和排除不能混用除了_id比如你不能写{ name: 1, email: 0 }这会报错。排序用sort分页用skip和limitdb.users.find().sort({ createdAt: -1 }).skip(20).limit(10)-1表示降序1表示升序。这里有个性能陷阱skip在数据量大时非常慢因为 MongoDB 要先扫描并丢弃前面 N 条记录。如果要做深度分页更好的方式是用范围查询比如记住上一页最后一条的createdAt下一页查{ createdAt: { $lt: lastCreatedAt } }。统计数量用countDocumentsdb.users.countDocuments({ status: active })老版本有count()方法但它在新版本中已经被标记为废弃因为它返回的是元数据估算值不准确。countDocuments会实际扫描并计数结果准确但慢一些。如果只是要个大概数量可以用estimatedDocumentCount()它直接读元数据非常快。3.2 插入、更新与删除的实操细节插入单条文档用insertOnedb.users.insertOne({ name: 张三, age: 28, status: active, createdAt: new Date() })插入多条用insertMany传入数组。这里有个细节insertMany默认是有序插入如果中间某条失败后面的不会继续。如果希望跳过失败继续插入可以加{ ordered: false }参数。更新操作是命令行的重头戏。updateOne更新第一条匹配的文档updateMany更新所有匹配的db.users.updateMany( { status: inactive }, { $set: { status: active, updatedAt: new Date() } } )更新操作符除了$set常用的还有$unset删除字段、$inc数值增减、$push数组追加、$pull数组移除。比如给所有用户年龄加一岁db.users.updateMany({}, { $inc: { age: 1 } })这里要特别提醒updateOne和updateMany如果不带更新操作符直接传一个文档会变成整体替换把原文档的其他字段全丢掉。比如db.users.updateOne({ name: 张三 }, { age: 30 })执行后张三的文档就只剩_id和age了name都没了。这个坑我踩过当时差点把生产数据搞坏。所以更新时一定要用$set这类操作符。删除用deleteOne和deleteManydb.users.deleteMany({ status: deleted })删除前建议先用同样的条件find一下确认要删的数据范围。我个人的习惯是执行deleteMany前先把条件改成find跑一遍看看数量对不对再换成deleteMany。3.3 聚合管道的实战应用聚合是 MongoDB 最强大的功能之一aggregate命令可以完成分组、统计、关联查询等复杂操作。基本结构是管道式的每个阶段处理完的数据传给下一个阶段db.orders.aggregate([ { $match: { status: completed } }, { $group: { _id: $userId, total: { $sum: $amount } } }, { $sort: { total: -1 } }, { $limit: 10 } ])这个例子是统计消费金额最高的前 10 个用户。$match过滤已完成订单$group按用户分组求和$sort降序排列$limit取前 10。$lookup可以实现类似 SQL 的 JOINdb.orders.aggregate([ { $lookup: { from: users, localField: userId, foreignField: _id, as: userInfo } } ])不过$lookup的性能开销比较大尤其是数据量大时。如果频繁需要关联查询可能要考虑把数据冗余存储用空间换时间。聚合管道里还有一个常用的$project阶段用来重塑文档结构db.users.aggregate([ { $project: { name: 1, age: 1, ageGroup: { $cond: { if: { $gte: [$age, 18] }, then: adult, else: minor } } } } ])这里用$cond做了条件判断根据年龄生成一个新字段。聚合表达式的功能非常丰富支持字符串处理、日期运算、数组操作等值得单独花时间研究。4. 索引管理与性能排查4.1 索引的创建与查看索引是数据库性能的命脉。没有索引的查询叫全表扫描数据量一大就慢得没法看。查看集合现有索引用getIndexes()db.users.getIndexes()创建索引用createIndexdb.users.createIndex({ email: 1 }, { unique: true })1表示升序-1表示降序。对于单字段索引升降序无所谓但复合索引的字段顺序和方向会影响查询能否命中。复合索引遵循最左前缀原则比如{ a: 1, b: 1 }这个索引能支持a的查询和a b的查询但单独查b用不上这个索引。创建索引时加{ background: true }可以让索引在后台构建不阻塞其他操作。不过在新版本的 WiredTiger 引擎中前台和后台索引构建的差异已经不那么明显了但生产环境建大索引还是建议在低峰期操作。唯一索引可以保证字段值的唯一性但要注意如果集合中已有重复数据创建唯一索引会失败。这时候需要先清理重复数据或者用{ unique: true, sparse: true }只对存在该字段的文档做唯一约束。TTL 索引是个很实用的特性可以自动过期删除文档db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })这样createdAt超过 1 小时的文档会被自动删除非常适合会话管理、临时日志这类场景。不过 TTL 索引的清理是后台线程定期执行的不是精确到秒通常有几十秒到几分钟的延迟。4.2 用 explain 分析查询性能explain是排查慢查询的利器。加上executionStats参数可以看到详细的执行统计db.users.find({ email: testexample.com }).explain(executionStats)返回结果里要重点看几个指标executionStats.executionTimeMillis执行耗时单位毫秒executionStats.totalDocsExamined扫描的文档数executionStats.totalKeysExamined扫描的索引键数winningPlan.stage获胜的执行计划阶段理想情况下totalDocsExamined应该接近返回的文档数如果远大于返回数说明索引没用好。winningPlan.stage如果是COLLSCAN说明走了全表扫描需要加索引如果是IXSCAN说明用上了索引。我遇到过一种情况查询条件里用了$regex做模糊匹配结果一直走全表扫描。原因是正则表达式如果以^开头且不是大小写敏感模式MongoDB 才能用上索引。如果正则中间有通配符索引就无能为力了。这种场景要么改查询方式要么上全文索引。4.3 慢查询日志与性能监控MongoDB 有个慢查询日志功能可以记录超过指定阈值的操作。查看当前设置db.getProfilingStatus()设置慢查询阈值单位毫秒db.setProfilingLevel(1, { slowms: 100 })级别0是关闭1是只记录慢操作2是记录所有操作。生产环境一般用1阈值设 100 到 200 毫秒比较合适。设置后慢查询会记录在system.profile集合里可以这样查询db.system.profile.find({ millis: { $gt: 100 } }).sort({ ts: -1 }).limit(10)这个集合是固定大小的 capped collection满了会自动覆盖旧记录所以不用担心无限增长。但要注意开启 profiling 本身有性能开销排查完问题后建议关掉或调高阈值。除了慢查询日志db.currentOp()可以查看当前正在执行的操作db.currentOp({ secs_running: { $gt: 5 } })这个命令能看到运行超过 5 秒的操作包括操作类型、涉及的库和集合、执行时间等。如果发现有长时间运行的操作可以用db.killOp(opid)终止它。不过 kill 操作要谨慎尤其是写操作强行终止可能导致数据不一致。5. 数据导入导出与备份恢复5.1 用 mongoexport 和 mongoimport 处理数据mongoexport可以把集合导出成 JSON 或 CSV 格式mongoexport --db myapp --collection users --out users.json导出 CSV 需要指定字段mongoexport --db myapp --collection users --typecsv --fields name,email,age --out users.csv这里有个坑CSV 导出时如果字段值里包含逗号或换行需要做转义处理否则导入时会错位。JSON 格式没有这个问题但文件会大一些。如果数据量特别大建议加--limit分批导出避免单文件过大。mongoimport用于导入数据mongoimport --db myapp --collection users --file users.json导入 JSON 数组格式时要加--jsonArray参数否则 mongoimport 会按每行一个文档解析遇到数组格式就报错。这个细节很容易被忽略我第一次用的时候就卡在这里。5.2 mongodump 和 mongorestore 做备份恢复mongoexport导出的是数据内容不包含索引和集合选项。如果要完整备份应该用mongodumpmongodump --db myapp --out /backup/mongodb/它会导出 BSON 格式的数据文件和元数据 JSON恢复时用mongorestoremongorestore --db myapp /backup/mongodb/myapp/mongodump支持压缩输出加--gzip参数可以显著减小备份文件体积mongodump --db myapp --gzip --out /backup/mongodb/恢复时对应加--gzipmongorestore --gzip /backup/mongodb/备份策略上我一般建议至少保留最近 7 天的每日备份加上每周一次的完整备份。如果数据量特别大可以考虑增量备份但 MongoDB 的增量备份需要结合 oplog 来做复杂度较高一般中小规模直接用全量备份就够了。恢复的时候有个注意事项mongorestore默认是追加模式如果目标库已有同名集合会往里面插入数据而不是覆盖。如果要先删除再恢复加--drop参数。这个参数在生产环境要慎用确认清楚再执行。6. 用户权限与安全管理6.1 创建用户与分配角色MongoDB 的用户是挂在数据库下的创建用户时要先切到对应的库use admin db.createUser({ user: adminUser, pwd: strongPassword, roles: [ { role: userAdminAnyDatabase, db: admin }, { role: readWriteAnyDatabase, db: admin } ] })常用角色有这么几类角色权限范围read只读readWrite读写dbAdmin库管理索引、统计等userAdmin用户管理clusterAdmin集群管理root超级管理员生产环境一定要遵循最小权限原则业务应用只给readWrite不要图省事直接给root。我见过有团队所有服务都用管理员账号连数据库结果一个服务被攻破整个数据库都暴露了。修改用户密码用updateUserdb.changeUserPassword(username, newPassword)删除用户用dropUserdb.dropUser(username)查看当前库下所有用户用show users查看所有库的用户需要切到admin库执行db.system.users.find()。6.2 认证配置与安全建议MongoDB 默认是不开启认证的这意味着任何人只要能连上端口就能操作数据。生产环境必须开启认证在配置文件里加上security: authorization: enabled开启认证后连接时必须提供用户名密码。如果之前没建管理员用户就开启了认证会把自己锁在外面所以顺序一定是先建用户再开认证。除了认证还有几个安全加固点值得注意。第一绑定 IP只监听内网地址不要暴露在公网net: bindIp: 127.0.0.1,192.168.1.100第二修改默认端口虽然不能根本解决安全问题但能减少被扫描的概率。第三启用审计日志记录所有敏感操作方便事后追溯。7. 常见问题排查与避坑经验7.1 连接类问题速查连接问题是最常见的我整理了一个速查表现象可能原因排查方法Connection refused服务未启动或端口不对netstat -tlnp检查端口监听Authentication failed用户名密码错或认证库不对确认--authenticationDatabasenot master连到了从节点检查副本集状态连主节点timeout网络不通或防火墙拦截telnet host port测试连通性too many connections连接数超限调大maxIncomingConnections认证失败这个问题特别常见很多时候不是密码错而是认证库搞错了。比如用户在admin库创建但连接时没指定--authenticationDatabase adminMongoDB 会去目标库找这个用户自然找不到。7.2 性能类问题排查思路性能问题排查有个基本顺序先看慢查询日志再用 explain 分析具体查询然后检查索引是否合理最后看服务器资源CPU、内存、磁盘 IO。一个典型的场景是某个查询突然变慢。排查步骤是先用db.currentOp()看有没有长时间运行的操作如果有看看它在干什么如果没有去system.profile里找最近的慢查询用 explain 分析执行计划。十有八九是索引问题要么没建索引要么索引被其他查询挤掉了。内存问题也值得关注。MongoDB 的 WiredTiger 引擎会用大量内存做缓存如果db.serverStatus().mem显示resident接近物理内存上限而virtual很大这是正常的。但如果出现频繁的 page fault说明内存不够需要考虑加内存或优化查询减少扫描量。7.3 我踩过的那些坑第一个坑是skip分页。早期做分页功能时用了skip limit数据量小的时候没问题数据上了百万级后翻到后面几页直接超时。后来改成基于游标的分页用上一页最后一条记录的_id或时间戳做条件性能立刻上来了。第二个坑是数组字段的索引。有次给一个数组字段建了普通索引查询时发现用不上。后来才知道数组字段要用多键索引multikey indexMongoDB 会自动识别数组并创建多键索引但复合索引里如果包含数组字段一个复合索引只能有一个数组字段多了会报错。第三个坑是$in查询的性能。$in里的值如果太多比如上千个查询会变得很慢因为 MongoDB 要逐个匹配。这种场景更好的做法是建一个临时集合把值导入进去然后用$lookup关联查询。第四个坑是更新时的类型变化。MongoDB 是模式灵活的同一个字段在不同文档里可以是不同类型。有次更新时不小心把数字字段更新成了字符串导致后续的数值比较查询全部失效。后来养成了习惯更新前先find看看字段类型用$type操作符确认。7.4 日常运维的实用技巧分享几个我日常用得比较多的技巧。第一个是用db.collection.stats()看集合的详细统计包括平均文档大小、索引大小、压缩比等。如果发现平均文档大小异常大可能有超大字段需要拆分。第二个是用db.collection.validate()检查集合完整性。这个命令会扫描集合和索引确认没有损坏。数据量大的时候会很慢建议在低峰期执行。第三个是用db.fsyncLock()和db.fsyncUnlock()做文件系统级别的备份。执行fsyncLock后MongoDB 会停止写入并把数据刷到磁盘这时候可以安全地复制数据文件。备份完记得fsyncUnlock否则数据库会一直处于锁定状态。第四个是db.setLogLevel()动态调整日志级别。排查问题时临时调高日志级别能看到更详细的信息排查完再调回去。不过日志级别调太高会产生大量日志注意磁盘空间。8. 命令行效率提升的进阶玩法8.1 自定义函数与脚本化mongosh支持 JavaScript可以定义自定义函数来简化重复操作。比如我经常需要按条件统计数量就定义了一个function countBy(collection, query) { return db.getCollection(collection).countDocuments(query) }定义后就可以直接countBy(users, { status: active })调用。这些函数在会话结束后就没了如果想持久化可以写到一个.js文件里启动时用--file参数加载mongosh --file /path/to/helpers.js更进阶的玩法是把常用操作写成脚本用mongosh直接执行mongosh mongodb://localhost:27017/myapp --eval db.users.countDocuments()--eval参数可以直接执行一段 JavaScript 并输出结果非常适合做定时任务或监控脚本。8.2 批量操作与循环处理有时候需要对多个集合执行相同操作可以用循环db.getCollectionNames().forEach(function(name) { var stats db.getCollection(name).stats() print(name : stats.count docs, stats.storageSize bytes) })这段脚本会遍历当前库所有集合打印文档数和存储大小。类似的思路可以用在批量建索引、批量清理数据等场景。批量更新时如果数据量特别大建议分批处理避免单次操作锁太久var batchSize 1000 var processed 0 while (true) { var docs db.users.find({ status: pending }).limit(batchSize).toArray() if (docs.length 0) break docs.forEach(function(doc) { db.users.updateOne({ _id: doc._id }, { $set: { status: processed } }) }) processed docs.length print(Processed: processed) }这种分批处理的方式虽然慢一些但对线上服务的影响小不会造成长时间的锁等待。8.3 监控脚本的编写思路最后分享一个简单的监控脚本思路。定期检查数据库的关键指标超过阈值就告警var stats db.stats() var connections db.serverStatus().connections print(Data Size: (stats.dataSize / 1024 / 1024).toFixed(2) MB) print(Storage Size: (stats.storageSize / 1024 / 1024).toFixed(2) MB) print(Index Size: (stats.indexSize / 1024 / 1024).toFixed(2) MB) print(Current Connections: connections.current) print(Available Connections: connections.available) if (connections.current / (connections.current connections.available) 0.8) { print(WARNING: Connection usage over 80%) }这个脚本可以配合系统的定时任务每小时跑一次输出重定向到日志文件再用日志分析工具做告警。虽然比不上专业的监控系统但在资源有限的情况下这种轻量级方案也能解决不少问题。我在实际使用中最大的体会是命令行的熟练程度直接决定了排查问题的速度。图形工具虽然直观但遇到复杂查询和性能分析时还是命令行更灵活、更高效。建议大家在日常开发中就多用命令行把常用命令练成肌肉记忆真到了紧急排查的时候才能不慌。
