MYSQL 按 UUID 列分区

Question

我在mysql中有一个表，需要根据UUID（版本1：包含时间戳+ MAC地址的组合）对列进行分区。

在 MySQL Aurora 中有 30 亿行和 6 TB 数据的表，预计在未来一年增长 50% 时会非常迅速地增长。

CREATE TABLE `org_info` (
  `ID` varchar(40) NOT NULL, UUID
  `ORGNAME` varchar(255) DEFAULT NULL,   
  `DATE_TIME` datetime(6) DEFAULT NULL,
  
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

希望根据ID列对该表进行分区，因为这是单个表，并且将来会增长得非常快。

我正在寻找对数据库非常陌生的帮助，我们如何根据 UUID 列对表进行分区？

Answer 1

您可以尝试hash或key 。更多信息在这里。

并且 UUID 的表示使用十六进制数字。您可以使用最后一个数字作为分区键。

Answer 2

原生格式的 UUID 作为一个巨大表的键是很糟糕的。 这是因为 UUID 值跳跃很多。 查找一行时，会加载包含该行的块 (16KB)。 该块中可能还有一百行（取决于行的大小和月相）。 由于随机性，在使用任何其他行之前，该块很可能会从缓存中弹出。 这使得缓存在很大程度上无用。 因此，处理非常受 I/O 限制。

添加分区，没有任何变化。 添加 UUID 的散列； 嗯，这是随机化已经随机化的东西——没有改善。 另一方面，如果您按日期进行分区，并且可以将查询限制为少于两个分区的数据，则分区修剪可能会有所帮助。 （我们可以进一步讨论。）

如果您有许多 TB 的数据，但只有一小部分在 RAM 中，您会认为几乎每次读取一行都需要一次 I/O 操作。 并且没有那么多可用的 IOP，即使使用 SSD，甚至使用 RAID 剥离。

写入同样糟糕——下一个进入的 UUID 必须读取-修改-写入一些可能不在缓存中的块（“buffer_pool”）。

在一种情况下，UUID 的成本可能较低，但它涉及到 Type-1 UUID 和大致按时间顺序排列的访问模式。 我在UUIDs中讨论了这一点。 MySQL 8.0 已经包含了其中的一些。 MariaDB 10.7（尚未 GA）使其成为一种数据类型。 （我不知道 Aurora 是否已经获得了这些改进。如果没有，请返回我的博客。）

如果该用例不适用，请描述您的应用及其对 UUID 的使用。 此外，如果有多个 UUID，让我们讨论所有这些 - 每个基于 UUID 的索引都有类似的性能问题。

通过将 36 个字符的 UUID 缩减为BINARY(16) （16 个字节），可以进行一项小的改进。 我的博客解释了如何做到这一点； 上面提到的版本是等效的。 无论如何，您必须更改代码以缩小数据。

根据您在问题中所说的话，一个简单的BIGINT AUTO_INCREMENT （8 个字节）可能会起作用，并且比任何 UUID 都好。 同样，分区是不合理的。