估计对大表进行分区所需的时间答案

【问题标题】：Estimating How Long It Takes To Partition A Large Table估计对大表进行分区所需的时间
【发布时间】：2023-01-18 10:20:49
【问题描述】：

我想弄清楚对一个大表进行分区需要多长时间。我对这张表进行分区大约需要 2 周时间，但我不太清楚需要多长时间。有什么方法可以计算此查询可能需要多长时间？

以下是有问题的查询。

ALTER TABLE pIndexData REORGANIZE PARTITION pMAX INTO (
    PARTITION p2022 VALUES LESS THAN (UNIX_TIMESTAMP('2023-01-01 00:00:00 UTC')),
    PARTITION pMAX  VALUES LESS THAN (MAXVALUE) 
)

对于上下文，pIndexData 表有大约 60 亿条记录，pMAX 分区有大约 20 亿条记录。这是一个 Amazon Aurora 实例，服务器运行的是 MySQL 5.7.12。数据库引擎是 InnoDB。以下是表格语法。

CREATE TABLE `pIndexData` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `DateTime-UNIX` bigint(20) NOT NULL DEFAULT '0',
  `pkl_PPLT_00-PIndex` int(11) NOT NULL DEFAULT '0',
  `DataValue` decimal(14,4) NOT NULL DEFAULT '0.0000',
  PRIMARY KEY (`pkl_PPLT_00-PIndex`,`DateTime-UNIX`),
  KEY `id` (`id`),
  KEY `DateTime` (`DateTime-UNIX`) USING BTREE,
  KEY `pIndex` (`pkl_PPLT_00-PIndex`) USING BTREE,
  KEY `DataIndex` (`DataValue`),
  KEY `pIndex-Data` (`pkl_PPLT_00-PIndex`,`DataValue`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (`DateTime-UNIX`)
(PARTITION p2016 VALUES LESS THAN (1483246800) ENGINE = InnoDB,
 PARTITION p2017 VALUES LESS THAN (1514782800) ENGINE = InnoDB,
 PARTITION p2018 VALUES LESS THAN (1546318800) ENGINE = InnoDB,
 PARTITION p2019 VALUES LESS THAN (1577854800) ENGINE = InnoDB,
 PARTITION p2020 VALUES LESS THAN (1609477200) ENGINE = InnoDB,
 PARTITION p2021 VALUES LESS THAN (1641013200) ENGINE = InnoDB,
 PARTITION pMAX VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

在研究这个问题时，我发现使用 Performance Schema 可以为我的问题提供答案。但是，此服务器上未启用 Performance Schema，启用它需要重新启动。重新启动不是一个选项，因为这样做可能会在处理此查询时损坏数据库。

为了了解这需要多长时间，我在一个单独的 Aurora 实例中重新创建了 pIndexData 表。然后我导入了一组样本数据（大约 300 万条记录）。示例集的 DateTime 值分布在 2021、2022 和 2023 年，其中大部分数据来自 2022 年。然后我运行相同的 REORGANIZE PARTITION 查询并计算完成所需的时间。分区查询耗时 2 分 29 秒。如果对记录的分区查询是线性的，我估计对原始表的查询大约需要 18 个小时。似乎没有线性计算。即使有很大的误差，这也很遥远。显然，我遗漏了一些因素（也许很多）。

除了使用更大的数据样本再次运行样本数据测试之外，我不确定还能尝试什么。在我这样做之前，我希望有人能了解如何最好地计算完成这可能需要多长时间。

【问题讨论】：

标签： mysql amazon-aurora data-partitioning

【解决方案1】：

添加（或删除）分区必然会将所有数据复制过来并重建所有表。因此，如果您的表大到足以保证分区（超过 100 万行），则将花费大量时间。

在REORGANIZE 一个（或几个）分区（例如PMAX）“INTO ...”的情况下，度量是PMAX 中的行数。

你什么应该所做的是在 PMAX 为空时在 2021 后期创建 LESS THAN 2022。

建议您将 PMAX 重组到 2022 年和2023 和 PMAX现在.同样，时间与PMAX 的大小成正比。然后务必在 2023 年 12 月创建 2024，此时 PMAX 仍为空。

【讨论】：