1. 性能故障诊断全景
MongoDB 的性能问题很少以单一、清晰的面貌出现。用户报障时说的往往是"系统变慢了"，但落到数据库层面，可能是某条查询突然从 5ms 涨到 800ms，可能是写入延迟从个位数毫秒攀升到数百毫秒，也可能是连接数在几分钟内被耗尽导致新请求全部排队。作为诊断者，第一步不是急着敲命令，而是把模糊的"慢"翻译成可观测、可量化的具体表现。
典型表现：四类可观测的异常信号
在 MongoDB 中，性能故障通常通过四类信号暴露出来，它们分别对应不同的资源维度，也指向不同的排查方向。
- 延迟类信号：查询响应时间上升、写入确认延迟增大。典型来源是缺少合适索引导致的全集合扫描（COLLSCAN），或索引选择性差导致扫描文档数远超返回文档数。
- 吞吐类信号：QPS 下降、单位时间处理的操作数减少。常见于锁竞争、WiredTiger 缓存不足引发的频繁磁盘读取，或副本集主节点写入压力过载。
- 资源类信号：CPU 使用率持续高位、磁盘 IOPS 打满、内存换页、网络带宽饱和。这类信号往往不是数据库自身逻辑问题，而是容量与负载不匹配。
- 连接与队列类信号：当前连接数逼近上限、操作在队列中等待、应用侧出现超时重试风暴。连接池配置不当或慢操作长期占用连接都会触发。
这四类信号并非孤立。一次全集合扫描会同时推高 CPU 和延迟，进而占用连接、拉低吞吐。诊断的价值就在于从这些相互纠缠的信号中，找到最先发生变化的那个环节。
诊断原则：先定位层次，再收敛根因
面对复杂性能问题，最容易犯的错误是"看到什么查什么"。更有效的做法是遵循三条原则。
第一，先分层再深入。把问题定位到应用层、数据库服务层、存储层还是网络层。应用层的慢可能来自 N+1 查询或序列化开销；数据库层的慢可能来自查询计划、锁或缓存；存储层的慢可能来自磁盘老化或 RAID 降级。层次定错，后续所有分析都会跑偏。
第二，用数据说话，避免猜测。每一个判断都应有对应的指标或日志支撑。怀疑索引缺失，就去看 explain() 的 totalDocsExamined 与 nReturned 的比值；怀疑锁竞争，就去看 serverStatus 中的锁等待计数。没有数据支撑的"我觉得"在复杂故障中几乎必然误导。
第三，从时间维度建立因果链。性能问题往往有明确的起点。把慢查询日志、指标曲线、应用发布记录、配置变更记录放在同一时间轴上对齐，通常能快速锁定触发事件。例如某次索引重建期间写入延迟飙升，时间对齐后因果关系一目了然。
核心工具链：从概览到细节的观测体系
MongoDB 自带了一套层次分明的诊断工具，配合操作系统级工具，足以覆盖绝大多数故障场景。
| 工具/命令 | 观测层次 | 典型用途 |
|---|---|---|
db.serverStatus() | 实例全局 | 连接数、操作计数、锁、WiredTiger 缓存、网络流量 |
db.currentOp() | 实时操作 | 查看正在执行的操作、耗时、是否等待锁 |
explain("executionStats") | 单查询 | 执行计划、扫描文档数、返回文档数、索引使用情况 |
慢查询日志（system.profile） | 历史查询 | 按耗时阈值捕获慢操作，分析高频慢查询模式 |
mongostat / mongotop | 实例/集合 | 实时吞吐、读写分布、集合级热点 |
db.stats() / collStats | 库/集合 | 数据量、索引大小、存储占用 |
操作系统工具（iostat、vmstat、top） | 主机 | 磁盘 IO、内存换页、CPU 分布 |
这些工具的使用有先后逻辑：先用 serverStatus 和 mongostat 建立全局印象，再用 currentOp 抓取实时异常操作，最后用 explain 和慢查询日志深入单条查询。反过来做，容易在细节中迷失而忽略全局瓶颈。
实战环境搭建：可复现的诊断沙箱
性能诊断能力必须在可复现的环境中训练。本节搭建一个单节点副本集环境，既能模拟真实副本集行为，又便于快速重置。
# 启动单节点副本集（示例环境，端口 27017）
mongod --replSet rs0 --dbpath /data/rs0 --port 27017 --fork \
--logpath /data/rs0/mongod.log
# 初始化副本集
mongosh --port 27017 --eval 'rs.initiate({_id:"rs0",members:[{_id:0,host:"127.0.0.1:27017"}]})'
# 确认主节点状态
mongosh --port 27017 --eval 'rs.status().members[0].stateStr'环境就绪后，导入一份可产生真实负载的示例数据集。以下脚本生成 50 万条订单文档，其中 status 字段基数低、customerId 基数高，便于对比不同索引策略的效果。
// 示例数据生成（教学用，非实测结果）
use perfLab
for (let i = 0; i < 500000; i++) {
db.orders.insertOne({
orderNo: "ORD" + i,
customerId: Math.floor(Math.random() * 50000),
status: ["pending","paid","shipped","done"][i % 4],
amount: Math.random() * 1000,
createdAt: new Date(Date.now() - i * 1000)
})
}
db.orders.countDocuments() // 预期 500000为了能主动制造故障，还需要开启慢查询分析并设置合理的阈值：
db.setProfilingLevel(1, { slowms: 50 })
db.getProfilingStatus()此时可以执行一条无索引查询验证环境是否可用：db.orders.find({customerId: 12345}).explain("executionStats")。在无索引情况下，totalDocsExamined 应接近 50 万，而 nReturned 仅为个位数——这个巨大比值正是后续章节要反复利用的诊断切入点。
全景视图：从信号到根因的收敛路径
把上述内容整合起来，可以用一张关系图表达诊断的整体逻辑：四类异常信号如何通过工具链被观测，又如何收敛到具体的根因类别。这张图不是操作步骤，而是帮助你在真实故障中快速判断"现在该看哪里"的认知地图。