做 MongoDB 运维这些年我最怕的不是写入慢、不是备份失败而是半夜被电话吵醒接起来就一句库好像卡住了。这种故障往往没有一个统一的前兆有时候是 CPU 飙升有时候是磁盘 IO 打满有时候干脆就是日志里一行看不懂的报错。但你要是把这类故障案例一个个拆开看最后基本都能收敛到几个固定的根因上慢查询没管住、索引没建对、锁等待被放大、连接数被打爆又或者是内存和磁盘这两个最容易被忽视的隐形瓶颈。这篇东西我不打算写那种 MongoDB 性能优化大全式的文章而是把我真实遇到过、也帮别人排查过的故障案例拿出来复盘。每个案例都有完整的排查链路、我当时看的关键指标、以及最后做了什么改动才恢复。如果你也在维护 MongoDB 实例或者正准备把业务迁到 MongoDB 上这些经验应该能帮你少走不少弯路。1. 线上数据库那些让人半夜爬起来的故障先盘点最常见的几种故障这东西表面上看千奇百怪实际上归归类就那么几大类。我先按我自己的实战经验把 MongoDB 最常见的故障场景列一下后面每个场景都会配真实的排查思路。1.1 从用户视角看故障卡、慢、断、丢用户不会管你是什么存储引擎、有没有建索引他们只关心一件事页面转不转得动。所以故障的第一感知永远是卡慢连接不上数据没了。对应到 MongoDB 这边就是下面这些现象查询响应时间从几毫秒变成几百毫秒甚至几秒前端接口超时告警CPU 使用率长时间跑满load average 持续走高MongoDB 日志里出现大量Slow query记录且sec数值越来越大应用端报Cannot connect to MongoDB或者连接池里的连接全部超时集群里某个节点掉线primary 发生切换副本集进入重新选举状态最严重的WT_CONNECTION_CLOSE或Fatal Assertion导致整个 mongod 进程退出还有一个经常被忽略的磁盘满了但你没看监控。我就遇到过几次客户说MongoDB 突然写不进去了上去一看磁盘 100%mongod 直接进入了只读模式No space left on device。这种故障一点都不高级但造成的损失比任何高阶问题都大。1.2 故障的本质几乎都能归到三类问题做的故障多了我会把问题归成三类排查时也按这个顺序来。第一类是查询问题。慢查询、全表扫描、返回数据量过大、排序没走索引。这类问题占了故障总量的一半以上而且最容易通过加索引和改写查询解决。第二类是资源问题。CPU、内存、磁盘 IO、带宽。这类问题往往是查询问题导致的果但有时候也是配置问题导致的因——比如 cache 太小、连接数太多、WiredTiger 的 checkpoint 间隔不合理。第三类是并发问题。锁等待、长事务、热点文档竞争。这类问题最隐蔽因为单看某一条查询可能都不慢但叠加在一起就会把库拖死。只要把故障归到这三类里排查就有方向了。下面我用三个真实案例把这几类问题逐个拆开。2. 一个典型的慢查询事故从用户投诉到 explain 计划的完整排查链路先说一个我印象很深的案例。那是一个电商类的业务某天晚上 8 点多业务方突然在群里说订单查询接口超时了数据库 CPU 飙到 90% 以上。我第一反应不是去看代码而是先看 MongoDB 的当前活动因为这种情况下最要紧的是先搞清楚是谁在吃 CPU。2.1 第一步用 currentOp 抓到肇事查询我登录到 mongod 所在的主机执行了这样一条命令db.currentOp({ active: true, secs_running: { $gt: 5 } })这条命令的含义是找出所有活跃且已经执行超过 5 秒的操作。返回结果里通常会包含op、ns、secs_running、planSummary这些字段。其中planSummary最重要它直接告诉你这条查询到底是走了索引还是 full collection scan。那次的结果里planSummary显示为COLLSCANns指向的是订单表的集合secs_running已经跑到了 80 多秒。一个订单查询居然全表扫描了 80 多秒不用再看别的问题基本就定位了。如果currentOp里的操作实在太多、刷屏刷得看不清我会加一个过滤条件只捞关键字段db.currentOp().inprog.forEach(function(op) { if (op.secs_running 5) { printjson({ opid: op.opid, ns: op.ns, secs_running: op.secs_running, planSummary: op.planSummary, msg: op.msg }) } })这里我特别提醒一句线上排查千万别随手执行db.currentOp()不带过滤条件的操作如果当前活动连接非常多这个命令本身会把控制台刷爆。先用secs_running过滤是最稳妥的。2.2 第二步定位到具体查询语句分析慢的原因有了ns和planSummary下一步就是找到那行查询语句本身。业务方通常会在日志里打出 MongoDB 查询日志但如果 log 没开完整就得靠currentOp里的command或originatingCommand字段去拼原始语句。当时看到的大致是这个形态db.orders.find({ user_id: u10086, status: { $in: [created, paid, shipped] }, create_time: { $gte: ISODate(2024-01-01) } }).sort({ create_time: -1 })单独看这条语句的逻辑其实很简单查某个用户在某段时间内的订单并按时间倒序。索引计划 COLLSCAN 意味着数据库把整个 orders 集合都扫了一遍然后才筛出符合条件的文档。为什么没走索引我先explain了一把db.orders.explain(executionStats).find({ user_id: u10086, status: { $in: [created, paid, shipped] }, create_time: { $gte: ISODate(2024-01-01) } }).sort({ create_time: -1 })执行结果里的winningPlan显示stage: COLLSCANexecutionStats.totalDocsExamined是 1800 多万totalKeysExamined是 0。这两个数字一出来问题就昭然若揭了查询条件里 user_id 和 create_time 涉及的索引根本没建或者建立了但没被选上。2.3 第三步建立复合索引然后验证效果我当时查了集合现有索引发现只有一个主键索引_id和status上的单键索引。status这个字段的基数是极低的也就几种状态值用它做等值过滤根本过滤不掉多少数据所以优化器宁愿全表扫也不用它。正确的做法是建立一个复合索引把等值字段放在前面范围字段放后面排序字段尽量由索引覆盖db.orders.createIndex( { user_id: 1, status: 1, create_time: -1 }, { background: true } )这里有个索引设计的关键点user_id是等值查询放最前面status也是等值查询放第二位create_time既是范围条件又是排序字段放到最后并设为-1来配合sort的降序方向。建立索引后再跑 explainwinningPlan变成了IXSCANFETCHtotalKeysExamined从 0 变成了几百totalDocsExamined和返回结果一致。接口响应从 3 秒多降到了 30 毫秒左右CPU 也从 90% 掉到了 20% 上下。2.4 慢查询排查的几个小技巧这个案例里我抓住了totalKeysExamined和totalDocsExamined这两个指标。前者是索引扫描的键数后者是回表读取的文档数。如果totalDocsExamined远大于返回的文档数说明索引选择性不够好如果totalKeysExamined也极大就要考虑复合索引的设计是否合理。再分享一个我自己的习惯给慢查询日志设置阈值平时就开起来。我一般会把 profiling 级别设为 1并且把阈值调到 500 毫秒use admin db.setProfilingLevel(1, { slowms: 500 })开了之后就能持续在system.profile里捞慢查询。虽然会有一点额外开销但对于线上业务来说这点开销换来的可观测性非常值。很多故障都是从小慢到大的早点发现早点处理就不至于半夜爬起来救火。3. 索引没生效的几种隐藏原因为什么建了索引查询还是全表扫慢查询的案例里有一种情况特别闹心明明建了索引explain 还是COLLSCAN。很多人会怀疑是不是 MongoDB 出 bug 了其实排查下来大部分都是索引设计和使用方式不匹配。下面这几个坑我都踩过列出来给大家排雷。3.1 坑一给低基数字段单独建索引这就是前面订单案例里status索引的问题。status只有五六种取值就算走索引扫出来的键还是接近全量。优化器算了一下成本发现用索引和全表扫差不多甚至全表扫更快就会直接选COLLSCAN。这里要理解 MongoDB 的查询优化器是会偷懒的它不是每个查询都做精确的成本估算而是靠定期采样和历史执行记录来决定计划。如果某个索引长期被判定为低效就会被淘汰出候选计划。遇到这种情况处理原则很简单不要给基数值很低的字段单独建索引要么不建要么放进复合索引里做后缀字段。3.2 坑二复合索引字段顺序写反了有很多人问为什么我建了{ status: 1, create_time: -1 }还是慢因为查询条件是user_id ? AND create_time ?索引里根本没有user_id这个前导字段MongoDB 无法直接利用索引的二分查找能力去定位。复合索引有个铁律等值条件字段放前面范围条件字段放后面。这跟 B 树的数据组织方式有关——索引字段的排列顺序决定了数据在树里的排序方式。前导字段换成等值条件才能在白驹过隙之间把区间缩小到最小范围。如果业务查询模式多没法用一个复合索引覆盖所有组合那至少保证每个查询的等值字段出现在索引的前缀里。这是索引选型的最低标准。3.3 坑三正则查询和取反条件不走索引db.users.find({ name: /^张/ })这种前缀正则其实能走索引但如果你写的是/张/不锚定开头优化器就没办法用索引做范围匹配了。更常见的问题是取反条件例如db.logs.find({ level: { $ne: debug } })$ne、$nin、$not这类操作符在大多数情况下是无法有效利用索引的因为 MongoDB 需要遍历所有索引键然后排除掉不符合的值这比正向扫描还费劲。如果业务里确实有排除少数值的查询可以考虑改写比如把非 debug改成level INinfo, warning, error之类的正向枚举索引就能用上了。3.4 坑四隐式类型转换把索引变成废纸这个坑最阴。MongoDB 的_id是 ObjectId如果你用字符串去查db.orders.find({ _id: 665f1a3f1c0a6b29f0e1a111 })虽然能查出结果但类型不匹配会导致它走不了_id索引的正确路径。更隐蔽的是一次业务上线把手机号字段从整型存成了字符串但老代码还在用整型去查结果就是原来秒回的查询变成了全表扫描。排查这类问题时我会用$type算子去验证字段的实际类型db.users.find({ phone: { $type: string } }).count() db.users.find({ phone: { $type: long } }).count()如果发现数据里有两种类型混存那就不要问了先做数据清洗再统一访问层的数据类型。这个坑在真实故障里非常常见而且极难一眼看出来。3.5 索引排查的系统化清单我现在遇到查得慢的第一反应不是去猜而是按顺序做下面几件事用 explain 看winningPlan是IXSCAN还是COLLSCAN看totalKeysExamined和totalDocsExamined的比例关系检查查询字段是否被复合索引前缀覆盖检查查询值类型与索引字段类型是否一致检查是否有正则、取反、函数包裹等无法走索引的写法检查索引字段的基数分布低基数字段谨慎建单键索引用db.collection.getIndexes()确认实际存在的索引把这套动作走完九成以上的慢查询都能找到原因。剩下的那一成基本就是资源问题或者锁问题了下面继续说。4. 锁与长事务另一个常见的卡死来源以及处理思路有一类故障的现象是所有写入都变慢读倒是正常的或者读也慢但查询条件很简单。这种一般不是索引问题而是并发控制出问题了。MongoDB 的 WiredTiger 存储引擎默认提供的是文档级并发控制但别以为文档级锁就不会出事热点文档和长事务一样能把你卡到怀疑人生。4.1 WiredTiger 锁机制的关键认知WiredTiger 的锁粒度是文档级别的理论上两个不同的文档可以并发写。但有个前提写操作必须先拿到事务 id再在提交时申请提交锁。到了提交那一步所有写操作都会竞争一把全局的 commit lock。如果某个持有锁的事务迟迟不结束后面的事务就全部排队。更麻烦的是意向锁机制。MongoDB 的 DDL 操作建索引、删集合会获取数据库级或集合级的意向锁。线上高峰期跑一个createIndex如果没有后台选项就可能把整个集合的读写全部堵住。我在前面创建索引时使用了{ background: true }这在 4.2 版本之后其实已经默认如此了。不过版本不同行为有差异建议大家在创建索引前先确认一下当前版本的建索引默认行为避免在高峰时段触发锁竞争。4.2 真实事故一个没提交的长事务拖垮了全部写入某次故障现象是主库 CPU 不高、磁盘也不忙、慢查询日志也没几条但业务写入超时率到了 20%。我排查了很久才发现罪魁祸首是一个打开了事务但忘记提交的应用代码逻辑。它的运行模式大概是应用收到某个消息后开启一个 MongoDB 事务在事务里做几次读和写但某条分支逻辑里没有调用commitTransaction也没有abortTransaction而是直接返回了。结果就是事务一直挂在那持有了一堆文档的写锁。MongoDB 里查这种僵尸事务用这个命令db.adminCommand({ currentOp: true, op: update, active: true })注意返回结果里的lsid逻辑会话 id和txnNumber还有每个操作的secs_running。如果看到某个操作的secs_running特别长同时它的lsid对应的事务一直没有 commit 或 abort那就是它在占着茅坑不拉屎。处理方式有两种一是让应用侧主动修掉不提交事务的 bug二是在紧急情况下手动杀掉会话db.adminCommand({ killSessions: [ { lsid: { id: uuid字符串 } } ] })kill 掉之后事务会回滚锁自然就释放了。但这不是治本的办法核心还是应用代码要保证事务的完整性try-catch-finally里必须 commit 或 abort 收尾。4.3 怎么避免长事务拖垮业务几点工程约束从此以后我给业务方定了几条硬性规范事务里绝对不做慢查询。事务中如果有全表扫描的查询等于长时间持有锁的同时还在大量扫盘这种组合是灾难。事务里不能做外部 IO。比如在事务中调第三方支付接口网络超时 30 秒事务就挂了 30 秒期间所有涉及文档都得排队。控制事务大小。一个事务涉及的文档数尽量控制在几十条以内腾讯和阿里云上的 MongoDB 官方文档都是这么建议的。设置事务超时时间。在客户端连接串里配置wtimeout和maxTimeMS让数据库和应用层都能把超过阈值的事务强制终止。如果你发现线上确实存在大量小事务竞争同一个热门文档可以考虑用update 的$inc、$set等原子操作替代先读后写的事务模式。很多时候事务不是必需的原子更新完全能解决。5. 资源侧的隐性问题内存、连接数、磁盘在什么情况下会拖垮数据库查询问题和锁问题聊完了最后说一类特容易被忽视的资源问题。前面提到那些 CPU 飙升、磁盘打满、连接爆炸的故障很多都是慢查询的并发症但也有一些是配置不当直接造成的。下面我逐个聊。5.1 内存WiredTiger Cache 和 Page Fault 的关系MongoDB 的 WiredTiger 引擎默认会使用系统可用内存的 50% 到 80% 作为内部缓存。这个缓存指标可以在 mongostat 里看mongostat --host 127.0.0.1:27017重点关注dirty、used、flushes这几列。如果dirty经常持续走高或者flushes频繁出现说明写入压力大内存缓存来不及刷盘最终会表现为磁盘 IO 飙升。还有一个指标叫page faults它代表 MongoDB 需要从磁盘加载数据页的次数。如果 page faults 很高说明内存缓存命中率不够数据经常要落盘读这种查询想快也快不起来。以前遇到过一种情况机器总共 64G 内存MongoDB 只用了默认配置WiredTiger cache 撑死 32G 左右但实际工作集超过了 40G导致频繁换页。后来按官方建议把 cache 调到了 48G也就是 75%page faults 立刻降了一个数量级。调整 cache 大小的方式是改配置文件storage: wiredTiger: engineConfig: cacheSizeGB: 48注意一个容易踩的坑cacheSizeGB 是给 WT 引擎用的不是给整个 mongod 用的。你要给操作系统留一部分页缓存空间所以别贪心调到 90%。我一般留 20% 给 OS让 OS 的 page cache 去承接那些读多写少的热数据。5.2 连接数几百还是一万区别很大很多应用用了连接池但连接池上限配置得极大比如 1000 甚至 5000。MongoDB 对这种 大量空闲连接 的处理机制是每个连接都会占用一个 thread每个 thread 都会耗内核资源。所以如果你看到连接数一两千但 CPU 不高数据库却经常无响应别急着加 CPU先把连接数降下来。查看当前连接数db.serverStatus().connections返回里current和available是最关键的。如果current长期逼近max说明连接池大小超出了实例承载能力。我一般建议线上最大连接池控制在 200 到 500 之间具体看业务的并发量和单个操作的耗时。一次查询 1 毫秒和一次查询 50 毫秒对连接的占用时长完全不一样。另外如果应用侧连接池收缩不及时会出现突发流量来一波连接数涨上去流量走了连接还挂着的情况。我通常会重开应用让连接池重建但这只能治标。从根上解决需要把客户端的maxPoolSize调到一个合理的值并且在 MongoDB 侧设置maxIncomingConnections做兜底。5.3 磁盘IO 延迟和空间告警都要盯磁盘问题分两种空间满了和 IO 延迟高。空间满了前面已经提过但有一个更隐蔽的变体删除数据后磁盘空间没释放。因为 MongoDB 删文档只是把空间标记为可复用并不会立刻还给操作系统。除非你用 compact 命令做物理回收否则 df 看到的空间占用可能一直居高不下。IO 延迟高的问题更麻烦因为它会放大一切问题明明一条查询可以走索引但因为索引页在磁盘上随机读延迟 20 毫秒多读几次就是几百毫秒。判断磁盘是否成为瓶颈可以用iostatiostat -x 2重点看%util和await。如果%util长期超过 80%await超过 30 毫秒基本说明磁盘跟不上业务了。SSD 和 NVMe 的指标阈值会好很多但也不要以为用了 SSD 就高枕无忧老一点的 SSD 在高压力下照样会 io 队列堆积。磁盘有问题时我的建议顺序是先确认是否有慢查询在放大磁盘压力再考虑缓存调优减少落盘读取最后才是升配磁盘。5.4 连接和资源之间的联动一个真实的全链路故障复盘把资源和查询串起来看才能理解一个故障为什么会连锁发酵。我经历过一次印象非常深的全链路故障某天下午订单服务出现偶发超时开始只有 5%然后逐步爬升到 30%。应用方排查发现是数据库慢查询增多把一个 3 秒的聚合分析任务从夜里挪到了白天跑它要扫描整年的订单数据。这个分析任务一跑CPU 开始爬升内存缓存命中率下降page faults 增多磁盘 IO 也开始上涨。磁盘的延迟反馈到了所有查询上包括平时 10 毫秒以内的点查也开始变慢。点查变慢后连接池里的连接长时间被占用应用端等不到可用连接就开始排队于是超时率进一步升高。从根上说这是一次低效查询 资源水位过高的联动事故。处理手段分了三步先把这个分析任务调回夜间执行接着给它加了能利用上的索引最后把应用连接池从 800 降到了 400。每一步都能缓解一部分压力三步下来系统完全恢复。6. 故障复盘建一个属于你自己的 MongoDB 体检清单每次故障处理完我都会强迫自己做一件事复盘。不是我自虐而是因为 MongoDB 的故障很少是一次性的同样的坑换个业务场景还会再踩一遍。下面这个体检清单是我压箱底的东西每季度或大版本升级后都会跑一遍。6.1 上线前必查的 10 个硬指标慢查询日志是否开启阈值是否合理profiling level 是否为 1slowms 是否在 300-500 毫秒区间每个集合是否都有适配查询模式的索引没有全表扫描的隐患复合索引字段顺序是否为等值前、范围后、排序靠索引是否有低基数字段单独建了索引连接池大小是否控制在合理范围maxIncomingConnections 是否有兜底WiredTiger cacheSizeGB 是否为物理内存的 50%-75%磁盘剩余空间是否 30%且删除操作是否有 compact 预案是否存在长事务或事务中嵌套外部 IO 的代码副本集节点之间的网络延迟和心跳时间是否正常这 10 条我每一条都踩过对应的事故看起来是检查项其实是排雷项。6.2 日常巡检的监控项建议监控别贪多就抓几个真正有用的mongostat里的command、query、update、delete吞吐指标db.serverStatus().wiredTiger.cache里的bytes currently in the cache和pages read from diskdb.serverStatus().connections的连接数趋势db.serverStatus().opcounters的读写比例db.currentOp()里活跃时长超过阈值的操作数量复制延迟db.printSecondaryReplicationInfo()看syncedTo与 primary 的时间差我给客户搭监控的时候一般会把这些指标做成 5 分钟的粒度。5 分钟对于 MongoDB 来说比较合适太细了噪音大太粗了故障回看时又不够用。6.3 一次完整的故障复盘模板故障处理完我会按下面的模板写一份复盘文档故障描述什么时间开始表现是什么影响了哪些业务根因分析是查询问题、锁问题、还是资源问题用 explain 或 serverStatus 佐证处理过程每一步操作的时间、命令、效果临时止血措施比如 kill 会话、关闭分析任务、调整 cache长期优化方案索引新增计划、代码改造规范、连接池调整监控预警改进这次故障如果提前看到哪个指标就能避免这个模板不是形式主义它最大的作用是让团队在下次遇到类似问题时能直接翻出上一次的处理方案不用再从零开始查。我有几次凌晨处理新故障就是靠着复盘文档里的旧方案快速稳住了局面然后白天再从容做根因治理。6.4 最后的心里话性能和故障是一体两面做了这么久 MongoDB一个最大的感受是性能优化本质上就是故障预防。你今天因为慢查询加了索引明天就少一次 CPU 飙升的告警你今天因为长事务卡库杀了会话明天就少一次写入超时的投诉。所谓的高可用不是靠某个玄学配置而是靠把每一个性能问题都按故障的态度去对待。如果让我给 MongoDB 运维/开发一条最核心的建议我会说把 explain、currentOp、serverStatus 这三个命令练到闭着眼睛都能用。它们一个管单查询健康一个管实时活动一个管全局水位。把这仨看懂了MongoDB 一半的疑难杂症在你这儿根本算不上疑难。