Mysql分区对DDL和DML的影响

时间:2018-12-04 15:29:44

标签: mysql database database-design ddl dml

我正在使用Mysql 5.6,在Transaction表(InnodB)中有约1.5亿条记录。随着大小的增加,该表变得难以管理(添加列或索引)并且即使需要索引也变慢。通过互联网搜索后,我发现现在是时候对表进行分区了。我相信分区将为我解决以下目的

  1. 改善DML语句的响应时间(使用分区修剪)
  2. 改善存档过程

但是我不确定是否(以及如何)改善此表的DDL性能。更具体地说,遵循DDL的性能。

  1. 更改表添加/删除列
  2. 更改表添加/删除索引

我浏览了Mysql文档和Internet,但找不到答案。任何人都可以在这方面帮助我或提供任何相关文档。

我的表结构如下

CREATE TABLE `TRANSACTION` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) DEFAULT NULL,
  `parent_uuid` char(36) DEFAULT NULL,
  `order_number` varchar(64) DEFAULT NULL,
  `order_id` int(11) DEFAULT NULL,
  `order_uuid` char(36) DEFAULT NULL,
  `order_type` char(1) DEFAULT NULL,
  `business_id` int(11) DEFAULT NULL,
  `store_id` int(11) DEFAULT NULL,
  `store_device_id` int(11) DEFAULT NULL,
  `source` char(1) DEFAULT NULL COMMENT 'instore, online, order_ahead, etc',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  `flags` int(11) DEFAULT NULL,
  `customer_lang` char(2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `parent_id` (`parent_id`),
  KEY `business_id` (`business_id`,`store_id`,`store_device_id`),
  KEY `parent_uuid` (`parent_uuid`),
  KEY `order_uuid` (`order_uuid`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

我正在使用以下语句进行分区。

ALTER TABLE TRANSACTION PARTITION BY RANGE (id)
(PARTITION p0 VALUES LESS THAN (5000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN MAXVALUE ENGINE = InnoDB)

谢谢!

1 个答案:

答案 0 :(得分:2)

分区不是性能的灵丹妙药。即使您提到的项目也不会加快速度;他们甚至可能放慢速度。

相反,我将批评该表以寻找加速某些事情的方法。

    一旦其上的索引变得太大而无法缓存, UUID的性能将很糟糕。这是由于其随机性。可能的解决方案:将其压缩为BINARY(16);用其他方法缩小桌子;避免使用UUID。
  • 为什么同时拥有parent_idparent_uuid
  • 在可行的情况下将4字节INTs缩小为较小的数据类型。
  • 通常CHAR应该是CHARACTER SET ascii(1个字节/字符),而不是utf8mb4(4个字节/字符)。
  • 警告:1.5亿将接近INT SIGNED的20亿限制。考虑INT UNSIGNED的4B限制。 (每个为4个字节。)
  • 您是否曾经使用created_atupdated_at
  • MySQL 8.0.13具有非常快的ADD COLUMNDROP COLUMN(在有限的情况下)。
  • 5.7。??与以前的版本相比,其ADD INDEX的侵入性较小,但是我不确定它是否适用于分区表。
  • 5.7.4:Online DDL支持减少了表重建时间并允许并发DML,这有助于减少用户应用程序停机时间。有关更多信息,请参见Overview of Online DDL

更重要的是,让我们看看“太慢”的主要查询。可能会有复合索引和/或查询的重新格式化可以加快它们的速度。

分区极有可能对有所帮助,但对PRIMARY KEY 没有帮助。

我认为有only 4 use cases分区有助于提高性能。