写操作卡在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，且不可并发
mongostat 的 qr|qw、netIn，mongotop 的热表分布，以及每个分片副本集的 replSetGetStatus 输出，比单纯看 CPU 和内存更有指向性。
