来自Scaling MongoDB一书：
一般情况
我们可以将其概括为分片键的公式： {coarseLocality：1，搜索：1}
所以我的问题是，这是正确的吗？不应该是更好写作的对立面吗？
同样来自书：
此模式继续：所有内容将始终添加到“最后” 块，意味着一切都将被添加到一个碎片中。这个分片键 给你一个不可分发的热点。
所以说我的应用程序总是按user_id搜索，并在集合中的最后一个条目。
我应该拥有的最佳分片键是什么，这个：
{_id:1, user_id:1}
或：
{user_id:1,_id:1}
答案 0 :(得分：7)
Kristina（ Scaling MongoDB 的作者）写了一篇博文，其中有一些以游戏为幌子解释的示例策略：How to Choose a Shard Key: The Card Game。
根据您的应用程序要求和用例，choosing a good shard key有许多注意事项。
{coarseLocality : 1, search : 1}命令的一般建议是确保您的数据有一些地方可供阅读。
因此，在您的情况下，您很可能需要：{user_id:1,_id:1}。
这将在查询时为同一user_id提供一些数据位置，理想情况下，您的常见查询将能够从单个分片中获取数据。
相反的顺序可以提供更好的写入分配（假设_id不是像默认ObjectId那样的单调增加的键），但潜在的缺点是reliability：如果读取查询的数据是分散的在所有分片中，如果任何一个分片出现故障，您将遇到检索问题。
所以说我的应用程序总是按user_id搜索，并在集合中的最后一个条目。
如果您经常按user_id搜索（并且没有_id），这也会影响您选择的分片键和index optimization。要查找MongoDB必须进行排序的最后一个条目;您将希望在单个分片上进行该排序，而不是必须从所有分片和排序中收集数据。如果您的_id恰好是基于日期的，那么作为分片键的一部分将有益于查找最后的条目。