mysql 估计对大型表进行分区所需的时间

mpbci0fu  于 2023-01-20  发布在  Mysql
关注(0)|答案(1)|浏览(281)

我正在计算对一个大表进行分区需要多长时间。我对这个表进行分区大约有两周的时间了,我不知道还要花多长时间。有什么方法可以计算这个查询可能需要多长时间吗?
下面是所讨论的查询。

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) */

在研究此问题时,我发现使用性能架构可以回答我的问题。但是,此服务器上未启用性能架构,启用它需要重新启动。重新启动不是一个选项,因为这样做可能会在处理此查询时损坏数据库。
为了了解这需要多长时间,我在一个单独的Aurora示例中重新创建了pIndexData表。样本集具有分布在2021、2022和2023上的DateTime值,然后我运行了相同的REORGANIZE PARTITION查询并记录了完成该查询所需的时间。分区查询花了2分钟,29秒。如果对记录的分区查询是线性的,我估计对原始表的查询大约需要18个小时。看起来不存在线性计算。即使有很大的误差幅度,这也是很不可能的。显然,我遗漏了一些因素(可能很多)。
除了使用更大的数据样本再次运行样本数据测试之外,我不确定还能尝试什么。在此之前,我希望有人能够了解如何最好地计算完成此测试所需的时间。

bvjveswy

bvjveswy1#

添加(或删除)分区将必然复制所有数据并重建所有表。因此,如果表足够大,需要进行分区(超过1 M行),则将花费大量时间。
REORGANIZE有一个(或几个)分区(例如PMAX)“INTO..."的情况下,度量是PMAX中有多少行。
您 * 应该 * 做的是在PMAX为空时在2021中创建LESS THAN 2022
建议你把PMAX重新组织成2022 * 和 * 2023和PMAX * 现在 *。同样,时间与PMAX的大小成正比。然后确保在2023年12月创建2024,那时PMAX仍然是空的。
按年分区的好处是什么?最终会清除旧数据吗?(这可能是唯一的好处。)
至于您的测试--当您测量2 m29 s时,其他分区中是否什么都没有?该测试将是正确的。添加2021索引行可能会有一个小负担。
旁注:以下是不必要的,因为有2个其他索引处理它:

KEY `pIndex` (`pkl_PPLT_00-PIndex`) USING BTREE,

不过,我不知道掉下去会不会“瞬间”。

相关问题