Troubleshoot Shard Keys对分片键进行故障排除

Jumbo Chunks巨型块

If you are seeing jumbo chunks, either the cardinality of your shard key is insufficient or the frequency of the shard key values is unevenly distributed.如果您看到的是巨型块，则可能是分片键的基数不足，或者分片键值的频率分布不均匀。

To increase the cardinality of your shard key or change the distribution of your shard key values, you can:要增加分片键的基数或更改分片键值的分布，可以：

• refine your shard key by adding a suffix field or fields to the existing key to increase cardinality通过向现有密钥添加一个或多个后缀字段来优化分片键，以增加基数
• reshard your collection using a different shard key with higher cardinality使用具有更高基数的其他分片键重新硬存储集合

To only change the distribution of your shard key values, you can also consider using Hashed Sharding to distribute your data more evenly.要仅更改分片键值的分布，还可以考虑使用哈希分片来更均匀地分布数据。

For advice on choosing a shard key see Choose a Shard Key.有关选择分片键的建议，请参阅选择分片键。

Uneven Load Distribution负荷分布不均

If your cluster is experiencing uneven load distribution, check if your shard key increases monotonically. 如果集群的负载分布不均匀，请检查分片键是否单调增加。A shard key that is a monotonically increasing field, leads to an uneven read and write distribution.分片键是一个单调递增的字段，会导致读写分布不均匀。

Consider an orders collection that is sharded on an order_id field. 考虑在order_id字段上分片的orders集合。The order_id is an integer which increases by one with each order.order_id是一个整数。

• New documents are generally written to the same shard and chunk. 新文档通常写入相同的分片和块。The shard and chunk that receive the writes are called hot shard and hot chunk. 接收写入的分片和块称为热分片和热块。The hot shard changes over time. When chunks are split, the hot chunk moves to a different shard to optimize data distribution.热分片随时间变化。当分割块时，热块移动到不同的分片以优化数据分布。
• If users are more likely to interact with recent orders, which are all on the same shard, the shard that contains recent orders will receive most of the traffic.如果用户更可能与最近的订单进行交互，这些订单都在同一个分片上，则包含最近订单的分片将接收大部分流量。

If you have a monotonically increasing shard key, consider resharding your collection. 如果您有一个单调递增的分片键，请考虑重新存储集合。For advice on choosing a shard key see Choose a Shard Key.有关选择分片键的建议，请参阅选择分片键。

If your data model requires sharding on a key that changes monotonically, consider using Hashed Sharding.如果数据模型需要对单调变化的键进行分片，请考虑使用哈希分片。

Decreased Query Performance Over Time随着时间的推移，查询性能下降

If you are noticing decreased query performance over time, it is possible that your cluster is performing scatter-gather queries.如果您注意到查询性能随着时间的推移而降低，那么您的集群可能正在执行分散-聚集查询。

To evaluate if your cluster is performing scatter-gather queries, check if your most common queries include the shard key.要评估集群是否正在执行分散-聚集查询，请检查最常见的查询是否包含分片键。

If you include the shard key in your queries, check if your shard key is hashed. 如果在查询中包含分片键，请检查分片键是否已哈希。With Hashed Sharding, documents are not stored in ascending or descending order of the shard key field value. 使用散列分片，文档不会按分片键字段值的升序或降序存储。Performing range based queries on the shard key value on data that is not stored in ascending or descending order results in less performant scatter-gather queries. 对未按升序或降序存储的数据执行基于范围的分片键值查询会导致性能较差的分散-聚集查询。If range based queries on your shard key are a common access pattern, consider resharding your collection.如果分片键上基于范围的查询是常见的访问模式，请考虑重新存储集合。

If you do not include the shard key in your most common queries, it is possible that you could increase performance by resharding your collection. 如果在最常见的查询中不包含分片键，则可以通过重新存储集合来提高性能。For advice on choosing a shard key see Choose a Shard Key.有关选择分片键的建议，请参阅选择分片键。