Question

我有一个带有PARTITION BY KEY PARTITIONS 10的表的表格;

Create Table: CREATE TABLE `table1 (
  `id` varchar(36) NOT NULL DEFAULT '',
  `ref_id` varchar(32) NOT NULL DEFAULT '',
  `target` varchar(50) DEFAULT NULL,
  `source` varchar(60) DEFAULT NULL,
  `t_time` DATETIME DEFAULT NULL,
  PRIMARY KEY (`id`,`ref_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
/*!50100 PARTITION BY KEY (`id`,`ref_id`) 
PARTITIONS 10 */

我想将此分区更改为PARTITION BY HASH PARTITIONS 20;但不确定如何在不丢失数据的情况下将Key更改为Hash。

请帮忙

Answer 1

两种分区方法都没有用;我建议删除分区。这样做，您可能应该从ref_id删除PRIMARY KEY。

如果您有理由相信分区在某种程度上有所帮助，我想进行辩论。

闻起来像id是UUID或GUID。如果性能是潜在的问题，我建议你使用BINARY缩小表（16）;有关转化的代码，请参阅my uuid blog。（较小 - >更快）

编辑（在这种情况下针对分区的争论）

一个常见的误解是将表分成较小的块会提高性能。让我们分析一下“点查询”，例如SELECT，您可以通过PRIMARY KEY指定一行。

在非分区表中，它将向下钻取BTree以查找该行。如果表格有几十亿行，则BTree将大约为5级。也就是说，查找将需要命中大约5个索引块才能找到实际的行。

在等效的Partitioned表中，每个分区都像一个较小的表。点查询需要（1）找到所需的分区，然后（2）向下钻取该分区中BTree中的4个级别。这是1 + 4操作 - 可能与非分区表中的5相同。

结论：点查询不会从分区中受益。

可能从分区中受益的其他类型的查询。例如，如果所有查询都针对分区，则可以更好地缓存该分区。但是“不能”在这里发生。该表在UUID（我假设）上进行了分区，例如非常随机，因此您无法仅查看一个分区。

如果您愿意分享常见问题，我可以进一步详细说明哪些（或其他）形式的分区受益（或不受益）。

Mysql Parition从Key变为Hash

1 个答案: