处理大型（UUID）作为MySQL表主键的最佳方法

26 浏览
0 Comments

处理大型（UUID）作为MySQL表主键的最佳方法

我有一个UUID字符串，我想将其用作MySQL表的主键，该UUID是一个32个字符的十六进制字符串（去除“-”字符后）。由于在数据库中最好使用数字列（int）作为主键，我想将其转换为整数，但不确定处理的最佳方法。

  1. 由于字符串的大小（即uuid='a822ff2bff02461db45ddcd10a2de0c2'），我是否需要将其分解成多个“子字符串”。
  2. 目前我在32位架构上运行PHP，因此无法在PHP中进行转换，因为PHP_INT_MAX的大小限制为0xFFFFFFFF。我怀疑MySQL也有相同的限制。
  3. 我不喜欢使用多个主键来修复此问题，我宁愿使用字符串表示，尽管这不是首选方法。

我可能对此有错误的理解，并且不排斥阅读文档，因此可接受示例或建议阅读作为回复。

0

3 答案

0 Comments

最佳的处理大型(UUID)作为MySQL表的主键的方法

在处理大型(UUID)作为MySQL表的主键时，我们面临的问题是如何处理大量的UUID数据，并且保证查询速度和性能。下面是解决这个问题的原因和解决方法。

问题的原因：

1. UUID是一个字符串类型，而不是整数类型。在处理大量的UUID数据时，使用字符串类型可能会导致性能问题。

2. 当我们需要进行查找操作时，使用UUID作为主键可能会导致查询速度变慢。

解决方法：

1. 使用字符串类型而不是整数类型。如果我们真的担心查询速度的问题，可以使用一个合成的自增主键。我们可以在UUID列上放置一个唯一约束，并且只使用它一次来查找合成主键，随后在连接等操作中使用合成主键。

2. 如果我们关心性能问题，可以考虑使用合成主键。但是，在记录数为数百万级别时，使用字符串类型可能不会带来性能问题，因此使用字符串类型的性能损耗并不大。

3. 生产质量的数据库（包括MySQL）具有非常聪明的索引算法来处理字符串查询。如果我们还不关心性能问题，那么为什么要在原始问题中遇到最大整数大小的限制呢？

4. 当然，我们可以将UUID以整数形式进行存储，但是为什么要费力去做这个操作，并且在以后的维护中增加额外的开销，如果它不能解决实际问题呢？

5. 如果我们担心性能问题，我们可以选择使用建议的解决方法来解决这个问题。

处理大型(UUID)作为MySQL表的主键的最佳方法是使用字符串类型，并且可以考虑使用合成主键来提高查询速度和性能。如果在处理数百万级别的记录时，使用字符串类型不会带来性能问题，那么我们可以选择使用字符串类型作为主键。如果以后需要优化，可以考虑使用合成主键来解决性能问题。

代码示例：

CREATE TABLE example (

id INT AUTO_INCREMENT PRIMARY KEY,

uuid CHAR(36) UNIQUE,

-- other columns

);

0
0 Comments

问题的出现原因：在MySQL表中使用大型UUID作为主键时，可能会遇到性能问题。

解决方法：将UUID存储为BINARY(16)类型，可以在MySQL中进行转换，而不是在PHP中进行转换。可以将UUID作为字符串绑定到bind_param方法中，然后将其指向binary(16)字段。

在大多数情况下，将UUID作为MySQL表的主键存储为BINARY(16)类型是最佳实践。可以参考以下相关的StackOverflow问题：UUID Performance in MySQL和How to Store UUID as Number。

转换工作应该在MySQL中进行，而不是在PHP中进行。无论你使用的是32位还是64位的PHP客户端，都不会有任何影响。

这正是我一直在寻找的。GUID/UUID不是由我生成的，而是从第三方来源获取的。作为主键，它是唯一的并且非常适用。我非常感谢你们的迅速回复，我已经给你们点赞了。谢谢你们的帮助。

你知道在MySQLi的bind_param方法中将UUID作为字符串绑定到binary(16)字段是否合法吗？我在弄清楚是否需要进行任何转换时遇到了困难。

0
0 Comments

在处理大量（UUID）作为MySQL表的主键时，最佳的处理方式取决于存储引擎。TokuDB应该可以解决所有这些问题。

UUID（Universally Unique Identifier）是一种全局唯一标识符，常用于分布式系统中的数据标识。在MySQL中，使用UUID作为表的主键可能会遇到一些问题。

1. 空间占用：UUID是128位的，相比于自增的整数类型，它会占用更多的存储空间。这可能会导致表的大小增加，占用更多的磁盘空间。

2. 索引性能：UUID的随机性导致插入新记录时，索引的数据分散在整个数据页中，而不是集中在某个特定的位置。这可能会导致索引的性能下降，查询速度变慢。

针对以上问题，使用TokuDB存储引擎可以解决这些问题。TokuDB是一个高性能的存储引擎，特别适用于大规模数据的插入和查询。它提供了以下解决方案：

1. 压缩存储：TokuDB使用了一种称为Fractal Tree的数据结构，可以有效地压缩数据，减少存储空间的占用。相比于其他存储引擎，TokuDB可以显著减小表的大小，节省磁盘空间。

2. 高效索引：TokuDB的Fractal Tree索引结构可以更好地处理UUID的随机性。它通过将索引数据分成小的块，并使用压缩和快速查找算法来提高索引的性能。这使得TokuDB在处理大量UUID作为主键时，能够更快地执行插入和查询操作。

如果需要处理大量UUID作为MySQL表的主键，尤其是对于大规模数据的处理，使用TokuDB存储引擎是最佳的处理方式。它可以通过压缩存储和高效索引来解决空间占用和索引性能的问题，提高系统的整体性能和效率。

-- 创建表时使用TokuDB存储引擎
CREATE TABLE my_table (
    id BINARY(16) PRIMARY KEY,
    ...
) ENGINE=TokuDB;

0