mongos批量写入性能瓶颈源于分片键设计、驱动线程配置与batchSize协同失衡；实测拐点通常在800–1200，需结合sh.status()、explain和mongos日志定位根因。
mongos批量写入性能差，batchSize设多大才不拖慢？
默认batchSize是1000，但实际中常卡在500–800就见顶——不是越大越好，而是受分片路由开销、网络吞吐和目标分片的写队列共同制约。超过临界点后，单批耗时陡增，反而拉低整体TPS。
实操建议：
- 先用
explain("executionStats")确认写入是否被拆成多个insert请求（即是否触发了跨分片广播），若出现shardFiltering或大量remote阶段，说明batchSize过大导致路由计算压力升高 - 压测时固定线程数（如16线程），逐步调高
batchSize：从100 → 200 → 500 → 1000 → 2000，记录每秒成功写入数和99分位延迟；拐点通常出现在800–1200之间 - 对含
_id自定义主键的集合，避免batchSize > 1000，因mongos需逐条校验_id唯一性并转发到对应分片，批量越大，校验+路由延迟越非线性增长
Java驱动里MongoClient线程池和bulkWrite怎么配才不抢资源？
驱动底层用Netty，bulkWrite本身不占线程，但并发调用时，每个请求会占用一个Netty event loop线程；若业务线程池远大于Netty线程数（如CPU核数×2），大量请求排队等待IO线程，造成虚假瓶颈。
实操建议：
- 检查
MongoClientSettings中ioThreadPoolSize（默认为Runtime.getRuntime().availableProcessors() * 2），不要盲目调大；生产环境建议设为cpu核心数 + 4，避免上下文切换开销 - 业务侧线程池大小 ≤
ioThreadPoolSize × 2，例如IO线程8个，业务写入线程最多设16个；再多只会堆积等待队列，不提升吞吐 - 禁用
maxConnectionLifeTime和maxConnectionPoolSize双高配置（如都设500），连接池过大会挤占系统文件描述符，且mongos端有默认maxConns限制（通常65535），超出后新连接被拒绝，错误信息是connection refused by peer
为什么batchSize=500时写入延迟突增？查sh.status()发现分片不均
batchSize影响的是单次请求的数据分布密度。如果分片键选择不当（比如用递增时间戳），大批量写入会集中打到同一个分片，触发该分片的writeLock争用，而其他分片空闲——此时看sh.status()会显示某分片chunks数量远高于其他，且balancer来不及迁移。
实操建议：
- 执行
sh.status()后重点看各分片的chunks数和size列，若差异超3倍，说明数据倾斜严重，batchSize再小也救不了 - 临时缓解：把
batchSize降到200以下，并在应用层做简单哈希分桶（如Math.abs(key.hashCode()) % 4），强制分散写入目标分片 - 长期解法：改用复合分片键，至少包含一个高基数字段（如
userId）+ 时间字段，避免单调递增导致的热点
调整batchSize后QPS没涨，mongos日志却频繁报slow query
这不是写入慢，是mongos在解析批量请求时花了太多时间——尤其当文档含嵌套数组、深层对象或$操作符（如$setOnInsert）时，每个文档都要做完整BSON解析和语法校验。batchSize越大，单批解析耗时越长，日志里就记成“慢查询”，但其实根本没到分片节点。
实操建议：
- 开启
mongos的详细日志：mongos --logpath mongos.log --setParameter enableTestCommands=1 --setParameter logLevel=2，过滤"command": "insert"日志，看"durationMillis"是否集中在解析阶段 - 避免在批量写入中混用不同结构文档（比如有的带
tags数组，有的没有），mongos会按最复杂结构做统一解析 - 若必须用复杂更新操作，改用
updateMany代替insertMany，让逻辑下沉到分片节点执行，减少mongos负担
真正卡住性能的往往不是batchSize数字本身，而是它暴露出来的分片键设计缺陷、驱动线程模型错配、或者mongos解析能力边界。调参前先看sh.status()和mongos日志里的durationMillis分布，比盲目改数字管用得多。
