在大型分区MySQL表中使用GUID作为主键

Question

在大型分区MySQL表中使用GUID作为主键

6

我们有一个包含数亿行的巨大InnoDB表，只有3列：GUID、枚举和smallint。所有查找都是通过GUID完成的。

我们正在考虑将GUID作为PK并按键进行分区。

我们听说使用GUID作为PK很糟糕，因为它的随机分布和PK创建聚集索引。因此，以GUID的随机顺序存储行会增加碎片和页面拆分。

使用GUID作为PK的替代方法是创建一个自增的代理键，并将其用作PK。然而，如果我们想按GUID对表进行分区，那么GUID也必须成为PK的一部分。此外，由于所有查询都是通过GUID完成的，我们需要一个额外的GUID索引。该索引本质上将GUID映射到PK，而如果我们使用GUID作为PK，则表本身将映射GUID->枚举+small int？

因此，我的问题是，通过添加自动增量PK并具有额外的GUID索引，我们是否能获得任何好处？

谢谢， Philopator。

- Philopator

1

GUID是否随机分布会成为问题，取决于您的访问模式。如果您是随机访问所有记录，则随机分布可能会给您带来更好的局部性 :) - Michael Mior

行被近乎随机地访问。所以，如果我理解你的意思正确的话，由于大多数是随机访问，即使是顺序自增ID也不会有太大帮助，对吗？我猜这是因为热页面的缓存？ - Philopator

1

没错。这也取决于写入的频率。如果写入非常频繁，将在相似时间创建的GUID放置在同一分区中以减少寻道时间仍然更有效。尽管如果您使用BBWC并在内存中缓冲写入，则这不是一个问题。 - Michael Mior

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jeremiah Gowdy · Accepted Answer

在InnoDB中使用GUID作为主键的问题不仅仅在于GUID分布是随机的，而是因为InnoDB中记录是按照主键顺序存储的。这意味着在你所讨论的表设计中，InnoDB将会不断移动数据以尝试对GUID进行排序。你应该使用一张转换表将GUID映射到int或bigint，并将其用作主键。