作者回复: 不会，因为根据user_id的值，你可以从config里面获得准确的shard#。只有少数几个（取决分片数）user_id 才需要跨分片。其他的都是指定分片

作者回复: chunk的是以片键值的upper bound 和 lower bound范围决定的。如果user_id是片键，那么对于user_id:1000，在他的email数量达到一定程度，不断分块后最后的就是： user_id >= 1000(包含1000） user_id < 1001( 不包含） 到了这一步，这一块里面只有他自己一个人的数据了。如果继续增长，你已经无法只用user_id这一个字段作为范围键来定义多余一个的chunk了。这时候就会早场超级块

作者回复: mongodb使用LRU算法对缓存数据进行管理。热数据和索引数据，他们本身的特性就决定了会经常被访问。你只要提供足够大小的缓存空间，他们自然就会被mongo留在缓存里，因为被经常访问缘故。 应用程序不用自己维护缓存数据。

作者回复: 你的理解正确。如果同一个userid下面的行数很多的时候，使用time可以将数据分布到多个块上。

作者回复: 在某一个shard的主节点上进行合并排序。 “mongos 是无状态的“ - 合并排序操作不需要记状态。但是确实不是在mongos做的。 和mysql/mycat架构上类似，但是对应用基本是全透明，使用上几乎和未分片的复制集没有区别。对程序员的使用体验更好

作者回复: 开始的时候你都是写入到同一个chunk，只有到了一定的量以后，超过chunk的阈值，chunk 会拆分变成2个或者更多，然后chunk会迁移到另一个分片。这个时候你的写入就会分布了。

作者回复: 分片是基于单表的。 不分片的集合默认留在主分片上。你也可以通过movePrimary 命令调整主分片所在位置。

作者回复: 1）可以，直接用shardCollection就可以 2）不会。 数据均衡可能会花很长时间（数天），这是正常的。

作者回复: 如果你的查询条件里有userid，就不会用到多个分片。 如果你的查询条件里没有userid，就会发散到多个片

作者回复: 官方没有标准算法 - 根据workload的不同，硬件配置可以差别很大。你可以参考MongoDB Atlas上面有个机器大小可以支持的Connections，所以从应用要支持的连接数，可以做一个反推。但是并不考虑你的数据量，所以只是个概括估计。 https://docs.atlas.mongodb.com/connection-limits/index.html