我最近读了一篇关于 Instgram 过去如何分片他们的 ID 的文章，他们使用一个独特的函数在他们的服务器上生成 ID https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c
但这让我很好奇是否可以将一个分片分配给特定用户而不是每个项目，以及它的性能如何。特别是在大型网站中。
因此，类似于以下的功能是否是一种有效的方法。
假设专用数据库上的用户表纯粹供用户使用。
用户-UID-名称-shardId
其中 shardId 是通过一个从 1 开始的函数计算的，对于每个新的插入，它都会递增 - 对于这个例子，最多为 n（比如 2048）。然后重置为 1。几乎充当循环法以在分片之间分发用户数据。
这种功能是否会对性能产生严重影响，尤其是在高负载期间？由于序列列只是从序列中选择一个 nextval，不是吗？这只是一个额外的步骤，一旦达到 n 就重置一个序列。还是我找错了树？
我一直在阅读 Pinterest 如何在此处对他们的 MySQL 数据库进行分片。
他们在那篇文章中谈论的一件事是拥有“单向‘映射’”表，例如
CREATE TABLE board_has_pins (
board_id INT,
pin_id INT,
sequence INT,
INDEX(board_id, pin_id, sequence)
) ENGINE=InnoDB;
然后是相反的pin_owned_by_board。
我的问题是，为什么你会有这些用于“映射”的“单向表”，而不仅仅是一个具有不同索引结构的表？我不认为它可以停止重复，因为序列是一个 unix 时间戳，但索引确实限制了只能通过board_id这个实例或完整索引（无论如何有效）进行选择。那么为什么不在board_id和上有单独的索引pin_id呢？这是不是因为一个 pin 理论上可以存在于一个单独的碎片上，即使他们试图将它们保持在同一个碎片上，所以让它成为“单向”是有意义的？