[当我阅读分片时，看起来作者并没有考虑必须将分片表加入的其他表（即使他们将分片描述为“原始数据库的子集”）。但是，这是非常普遍的情况，我仍然不知道如何处理。一些作者提到由分片表引用的“静态”表，该表可以复制到每个分片（例如，Country）。但是，他们对引用分片的表一无所知。
想象一下，我们运行一个社交网络，并意识到我们的User表（id，name）不再适合单个服务器，原因是写入量很大或大小（或两者兼而有之） 。因此，我们决定将其水平划分为多个分片（例如，4，因此ID为1-1000的用户转到一个分片，1001-2000的用户转到另一个分片，等等），然后选择User.id作为分片密钥。由于User表通常与其他表联接，因此我们将记录从引用给定用户或由其引用的表中移到相应的分片（这是一个很大的挑战，因为关系通常是可传递的，例如，表A可能参考B，它引用了分片表C）。为了简化操作，我们可以决定将除User表之外的所有表全部复制到所有分片。到目前为止一切顺利。
然后，想象Friends表（id，user_id，friend_id），其中包含有关谁是谁的朋友的信息并引用User表。用户1001有2个朋友2002和3003，它们位于不同的分片上。因此，如果我们需要获取有关用户1001朋友的信息，我们将必须执行2个交叉分片联接。即使我们最初设法将所有相关用户放在同一分片上，用户也可以从其他分片添加新朋友。我们无法将此朋友4004移至用户1001，因为来自同一分片＃5的其他用户也可以将其作为朋友。
老实说，我无法弄清楚执行分片时如何处理这种情况，而且我还没有看到任何资源对此进行解释。
当跨分片表进行联接时，通常要优化的是跨分片传输的数据量。
有5种类型的分布式联接，如here所述，从最喜欢的顺序到最小的顺序：
这是您在Countries表中提到的示例。每个节点都在本地保留此表的副本，因为它很少更新。优点和缺点很明显：并非所有内容都可以标记为参考表，但是不涉及数据移动。
这意味着向连接所需的数据所在的所有节点发送查询。然后，汇总整体执行结果。缺点是需要将表分片到连接条件中涉及的列上。这是最具可扩展性的算法，因为在进行连接之前不涉及任何数据移动。
这将与您的Friends表示例一起使用。大概，您的Users表将由用户ID（也是分片键）进行键控，因此将有一个索引，因此查询应该很快。
集群中的所有节点将连接两侧的数据发送到单个节点，以便它可以运行连接。仅当连接中涉及的行数很少时，这种类型的连接才能很好地执行。
[如果您要进行联接，则其中一侧的数据集较大，而另一侧的数据集较小，则此类型会将较小的数据集发送给较大的数据集，而具有较大数据集的节点将在本地进行联接。
这是运行分布式联接的最昂贵但最灵活的方法。由于连接中涉及的许多行都复制到其他节点以执行连接，因此需要大量数据移动。