在大分区MySQL表中使用GUID作为PK

我们有一个庞大的InnoDB表，有数亿行，只有3列：GUID、enum、smallint。 所有查找都是通过GUID完成的

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

我们听说使用GUID作为PK是不好的，因为它是随机分布的，而且PK会创建聚集索引。因此，以guid的随机顺序存储行会增加碎片和页面分割

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

所以我的问题是，通过添加autoincpk和额外的GUID索引，我们是否获得了什么

谢谢，

---

Philopator.

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

GUID随机分布的事实是否是一个问题取决于您的访问模式。如果您随机访问所有记录，那么随机分布可能会提供更好的位置：）这些行几乎是随机访问的。所以，如果我理解正确的话，由于大部分是随机访问，即使是顺序自动公司id也不会有多大帮助，对吗？我猜这是因为缓存热页？没错。这还取决于写入的频率。如果写操作非常频繁，那么将在类似时间范围内创建的guid放在同一分区中以减少查找时间仍然会更有效。虽然如果您使用BBWC并在内存中缓冲写操作，这不是一个问题。是的，COMB GUID也解决了这一问题，但是您仍然拥有比使用转换表设计更宽的键。