Mysql分区对DDL和DML的影响

Question

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

1. 提高 DML 语句响应时间（使用分区修剪）
2. 改进归档过程

但我不确定它是否（以及如何）提高该表的 DDL 性能。更具体地关注 DDL 的表现。

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

我浏览了 Mysql 文档和互联网，但找不到我的答案。谁能帮助我或为此提供任何相关文件。

我的表结构如下

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)

谢谢！

Answer 1

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

相反，我会评论表格以寻找加快某些事情的方法。

• 一旦 UUID 上的索引变得太大而无法缓存，它的性能就会变得很糟糕。这是因为它的随机性。可能的解决方案：将其压缩为BINARY(16)；以其他方式缩小表格；避免使用 UUID。
• 为什么parent_id 和parent_uuid 都有？？
• 将 4 字节的 INTs 缩小为更小的数据类型在可行的情况下。
• 通常CHAR 应该是CHARACTER SET ascii（1 字节/字符），而不是utf8mb4（4 字节/字符）。
• 注意：150M 正在远程接近INT SIGNED 的 20 亿限制。考虑INT UNSIGNED 的4B 限制。 （每个为 4 个字节。）
• 你用过created_at或updated_at吗？
• MySQL 8.0.13 有一个非常快的ADD COLUMN 和DROP COLUMN（适用于有限的情况）。
• 5.7.??与以前的版本相比，ADD INDEX 的侵入性更小，但我不确定它是否适用于分区表。
• 5.7.4：Online DDL 支持减少了表重建时间并允许并发 DML，这有助于减少用户应用程序停机时间。如需更多信息，请参阅Overview of Online DDL。

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

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

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