隐式创建的集合不会自动分片，因为分片需显式调用sh.shardCollection()启用；隐式创建仅初始化元数据，不配置分片策略，即使数据库已启用分片（partitioned: true），集合仍默认位于primary shard且未分片。
隐式创建的集合为什么不会自动分片
因为MongoDB的分片是显式启用的机制，不是存储层默认行为。隐式创建只触发集合元数据初始化，不触达分片系统任何配置环节。
db.collection.insertOne()执行时到底发生了什么
这条命令在mongos或单机mongod上执行时，仅做三件事：检查集合是否存在、若不存在则调用createCollection（无参数）、插入文档。它完全不读取config.databases，也不向config.shards写入任何分片策略。
- 隐式创建等价于
db.createCollection("coll")，而非sh.shardCollection("db.coll", {key: 1}) - 即使数据库已启用分片（
partitioned: true），集合本身仍是not sharded - mongos路由层对未分片集合的请求，直接转发到该库的
primary shard，不查config.chunks
误以为“启用了分片”就等于“所有集合都分片”的常见错觉
很多人看到sh.enableSharding("mydb")成功返回，就认为后续所有集合都会自动分片。但这个命令只改config.databases里的partitioned字段为true，它只是“允许建分片集合”的开关，不是“强制分片”开关。
-
sh.status()里显示"databases" : [ { "database" : { "name" : "mydb", "partitioned" : true } } ]，不代表里面任何集合已分片 - 真正分片必须对每个集合单独执行
sh.shardCollection("mydb.coll", {shardKey: 1}) - 如果跳过这步，
db.coll.find()查到的数据永远只在primary shard上，其他shard上为空
为什么MongoDB不设计成“自动分片隐式集合”
这是有意为之的工程取舍：分片涉及片键选择、chunk分布、均衡器调度、迁移风险等强业务耦合决策，无法由系统代劳。
- 片键选错会导致写入热点——比如用
timestamp做范围分片键，在高并发日志场景下所有新数据全挤进最后一个chunk - 隐式创建时根本不知道业务语义，无法判断该用哈希分片还是范围分片，也无法预估基数和查询模式
- 自动分片还意味着自动开启均衡器，而
sh.startBalancer()可能影响线上写入延迟，必须人工确认时机
最常被忽略的一点：隐式创建 + 未手动分片，会让集合长期卡在primary shard上。一旦该shard磁盘告警或IO瓶颈，整个库的未分片集合都会受影响，且无法用movePrimary挪走旧集合——只能重建并重新导入。
