我想知道如果行的ID以非统一的方式生成，理论上是否会遇到麻烦。我是否会遇到这样的问题，即很难根据主键对数据库表进行分片？
我不能直接控制这些ID，因为我们的客户使用我们的API和SDK，他们决定了ID。他们可能会使用UUID v4或其他类似的UUID生成器，但我不能轻易地强制执行这一点，我也不想。
我想也许postgres会足够聪明，可以自动散列主键，非加密方式，例如使用xxHash，以避免基于主键的分片可能导致不平衡分片的分片问题。这是数据库的标准实践吗？还是数据库通常假设用户将生成分布良好的主键？
1条答案
按热度按时间u2nhd7ah1#
首先，关于分片的一些考虑，因为这似乎是你提出问题的原因：
我想说，基于人工生成的主键列对表进行分片是一件相当不寻常的事情，除非
WHERE id = ...搜索那个表和
如果您可以将数据库拆分为几乎没有互连的分片，则分片通常很有用，例如，将每个客户的数据存储在不同的数据库中。
所以我认为你应该更努力地思考如何以及为什么要对数据库进行分片，然后再开始思考PostgreSQL如何存储字符串主键。
但对于你最初的问题：PostgreSQL存储的字符串就像它们一样（除非它们很长，在这种情况下，它们被压缩并存储在行外，但这样的值不能用作主键）。所以，不，引擎盖下没有哈希。
这也适用于标准的B树索引：字符串按原样存储（这很重要，因为它们必须按字母顺序排列）。PostgreSQL中有散列索引，它不会存储字符串，但它的散列值，但这样的索引不能是唯一的，所以它们不能用作主键索引。
任何你想做的散列，你必须自己做，例如
hashtext(id)。如果您知道这些值将是UUID，请不要使用字符串数据类型，而是尽一切可能使用
uuid。