如何识别并解决MongoDB分片集群里的隐性写操作性能问题？

写操作卡在mongos路由层主因是分片键缺失或类型不匹配导致广播写入；需检查写语句是否含正确分片键、启用config server慢日志定位SHARDING_FILTER操作，并避免无分片键的updateMany/deleteMany。

写操作卡在 mongos 路由层，而不是分片本身

很多慢写问题其实根本没到分片节点，而是卡在 mongos 的查询路由和分片键解析阶段。典型现象是：mongostat 显示 qr|qw 队列高、netIn 持续上涨，但各分片的 insert 和 query 数值却很低。

原因通常是写入语句未包含分片键，或分片键字段类型/结构与分片定义不一致（比如定义为 {user_id: "hashed"}，但实际写入时传的是字符串而非数字）。mongos 无法定位目标分片，只能广播写请求或阻塞等待元数据刷新。

• 用 db.setProfilingLevel(2, {slowms: 10}) 在 config server 上开启全量慢日志，重点查 command 类型为 insert 或 update 且 planSummary 为 SHARDING_FILTER 的条目
• 检查应用层写入语句是否显式包含分片键字段，且值非空、类型匹配（可用 typeof 或 instanceof 在 driver 层校验）
• 避免对分片集合执行无分片键的 updateMany 或 deleteMany —— 这类操作会触发全分片广播，且默认不带 writeConcern 限制，极易拖垮 mongos

分片键设计导致写入热点，但监控指标不明显

写入集中在单一分片上，CPU 和磁盘 IO 看似正常，但 mongotop 显示某一分片的某个集合耗时占比长期超 60%，且该分片的 chunks 数远少于其他分片（如只有 2–3 个 chunk，而其他分片有 20+）。

这说明分片键缺乏足够离散性：比如用时间戳前缀的 _id、自增 ID、或固定值字段（如 tenant_id 在 SaaS 场景中多数为同一值），导致新写入持续落到同一个 chunk，进而无法触发自动均衡。

• 运行 sh.status() 查看各分片的 chunk 分布，重点关注 balancer 是否处于 “active” 状态，以及是否有分片长期显示 no chunks 或 chunks: 1
• 用 db.collection.getShardDistribution() 获取具体分布热力，比 sh.status() 更直观
• 切勿在已有大量数据的集合上直接修改分片键；若必须调整，先用 sh.splitAt() 手动切分热点 chunk，再配合 sh.moveChunk() 迁移，最后考虑重建分片（需停写）

oplog 同步延迟引发隐性写阻塞

主分片写入速度正常，但从节点同步滞后（replSetGetStatus 中 optimeDate 差值 >30s），且应用层出现偶发性写超时或 WriteConcernError。这不是网络或硬件问题，而是副本集内部同步跟不上写压力，导致 mongos 等待 write concern 满足时被拖住。

尤其在启用 w:majority 时，只要有一个从节点掉队，所有满足 majority 的写操作都会卡住——即使它只影响一个分片，也会让整个集群写入变慢。

• 检查每个分片副本集的 oplogSizeMB：写密集场景下低于 4096MB 容易溢出，造成从节点无法追平；建议按日均写入量 × 24 小时估算
• 确认从节点硬件配置不低于主节点，特别是磁盘 IOPS；SSD 是底线，HDD 在写入高峰必然拖后腿
• 临时缓解可降级 write concern（如改用 w:1），但需权衡一致性；长期方案是扩容从节点或优化慢查询减少 oplog 压力

配置服务器元数据锁争用，影响写路由决策

集群写入吞吐突然下降 50% 以上，mongostat 显示 config 连接数飙升，mongos 日志频繁出现 Failed to refresh metadata from config server。此时分片节点本身负载不高，但写入几乎停滞。

这是配置服务器副本集（config server replica set）成为瓶颈的典型信号。所有写路由都依赖 config server 提供的分片元数据（chunk map），一旦其响应变慢或选举中，mongos 会缓存旧元数据并重试，造成写请求堆积。

• 确保 config server 使用独立物理机或高配容器，禁用与其他组件共用资源
• 检查 config server 的 oplog 大小和磁盘延迟；其 oplogSizeMB 至少应为数据分片的 1.5 倍
• 避免高频执行 sh.splitAt()、sh.moveChunk() 等元数据变更操作——这些会直接写入 config server，且不可并发

写操作性能问题最难排查的点，往往不在“慢”，而在“看起来不慢却集体卡顿”：mongos 路由延迟、chunk 均衡失效、oplog 同步断点、config server 元数据锁，这四类问题都不会立刻报错，但会让写入吞吐无声衰减。盯住 mongostat 的 qr|qw、netIn，mongotop 的热表分布，以及每个分片副本集的 replSetGetStatus 输出，比单纯看 CPU 和内存更有指向性。