MongoDB 6.0+ 已彻底移除自动分块机制，sh.enableAutoSplit()等命令无效；分裂仅发生在手动操作或均衡器迁移前校验时，核心问题在于分片键设计不当而非配置错误。
自动分块（auto-split）在 MongoDB 6.0+ 已被禁用
从 MongoDB 6.0.3 开始，sh.enableAutoSplit() 和 sh.disableAutoSplit() 命令仍然存在，但**完全不执行任何操作**。这不是 bug，而是官方主动移除：均衡策略改由更智能的 chunk 迁移与大小调控驱动，不再依赖“插入/更新触发即时分裂”这一老机制。
常见错误现象是：明明数据持续写入、chunk 明显超大（比如 >128MB），却始终没见自动拆分，sh.status() 中 chunks 数量长期不变。别查 mongos 日志了——它压根没尝试 split。
- 6.0 之前：写入或更新单个文档可能触发 chunk 分裂（前提是超出当前
chunkSize） - 6.0 及之后：分裂只发生在 手动干预 或 均衡器迁移前校验 阶段（例如 moveChunk 检测到目标 chunk 太大而拒绝迁移，此时会先分裂）
- 你无法“重启 auto-split 守护进程”，因为这个进程已不存在；
mongos不再承担分裂调度职责，它只做路由和命令转发
chunkSize 修改后为什么没立刻生效
修改全局 chunkSize（单位 MB）只是设了个“目标上限”，现有 chunk 不会自动重切。MongoDB 只会在特定时机检查并执行分裂：
- 均衡器运行时，准备迁移某个 chunk，发现它 > 新
chunkSize× 1.1（预留缓冲），就会先分裂再迁移 - 你手动执行
sh.splitAt()或sh.splitFind() - 集合刚开启分片时，初始 chunk 按新
chunkSize划分（但仅限首次）
所以减小 chunkSize 后，得等均衡器活跃 + 有 chunk 触发迁移，才逐步看到分裂效果。如果集群负载低、无迁移需求，可能几小时都没动静。别误以为配置失败。
设置命令示例（连接任意 mongos）：
use config<br>db.settings.updateOne({ _id: "chunksize" }, { $set: { value: 64 } }, { upsert: true })
均衡器不运行 ≠ 分块失效，但可能是真卡点
sh.isBalancerRunning() 返回 false 很常见，不代表故障——它只表示“此刻没有迁移任务正在执行”。但如果你扩容后数据长期滞留在旧分片（如某 shard 占 95% 数据），那问题大概率出在 chunk 太大导致迁移失败。
典型错误日志：
ChunkTooBig: Cannot move chunk: the maximum number of documents for a chunk is 114640, the maximum chunk size is 67108864这说明 chunk 超过默认 64MB，且均衡器拒绝搬运，又不会自动切分，于是卡死。
- 临时解法：对具体集合单独调大 chunkSize，用
db.adminCommand({ configureCollectionBalancing: "db.coll", chunkSize: 256 }) - 根治方向：检查分片键是否单调（如
order_id）、基数是否太低（如只有 3 个school_id值），这些会导致 chunk 天然巨大且无法均匀分布 - 别指望
mongos“唤醒”分裂逻辑——它没这个功能；所有分裂动作必须由你触发，或靠均衡器在迁移上下文中被动触发
真正该盯住的不是 auto-split，而是分片键设计
很多团队花几小时调 chunkSize、查 mongos 日志，最后发现：无论怎么调，总有一两个 chunk 巨大无比，永远移不动。根源几乎都在分片键上。
- 如果分片键值高度重复（比如
{ status: "active" }），所有文档挤进同一个 chunk，chunkSize再小也无解 - 如果分片键单调递增（如
timestamp），新数据全写到末尾 chunk，它会不断膨胀，直到触发迁移失败 - 哈希分片（
{"uid": "hashed"}）能强制分散，但代价是丧失范围查询能力——得看你业务是否接受
重新分片（sh.reshardCollection()）是 MongoDB 5.0+ 提供的补救手段，但它要求集合无活跃写入、耗资源、有锁表风险。比起事后抢救，一开始选对分片键成本低得多。
容易被忽略的一点：即使你把 chunkSize 设成 1MB，只要分片键设计不当，chunk 依然会迅速突破限制——机制可以调，但数据分布规律改不了。
