Mysql重组算法

我对Mysql/MariaDB上的分区合并有一个问题

我的桌子是这样的：

按范围划分（到_天（`mydate`））
(
分区p_第一个值小于（到_天（'2019-03-01'））ENGINE=InnoDB，
分区p201903值小于（到_天（'2019-04-01'））引擎=InnoDB，
分区p201904值小于（到_天（'2019-05-01'））引擎=InnoDB，
分区p201905值小于（到_天（'2019-06-01'））引擎=InnoDB，
分区p201906值小于（到（2019-07-01）天）引擎=InnoDB，
分区p201907值小于（到_天（'2019-08-01'））引擎=InnoDB，
分区p201908值小于（到_天（'2019-09-01'））引擎=InnoDB，
分区p_未来值小于（MAXVALUE）ENGINE=InnoDB
);

pfirst的

pfirst

分区非常大（5亿行），分区对于获取上个月的数据非常有用

每月我们将最旧的分区

p201903

与

pfirst

合并，并拆分

p\u future

，使用以下查询创建新分区（

p201909

）：

ALTER TABLE mytable将分区p_first、p201903重新组织为（分区p_first值小于（TO_DAYS（'2019-04-01'））；

及

ALTER TABLE EB_position将分区p_future重新组织为（分区p201909值小于（TO_DAYS（'2019-10-01'））ENGINE=InnoDB，分区p_future值小于（MAXVALUE）ENGINE=InnoDB）；

从技术上讲，mysql是如何做到这一点的？ mysql正在创建新的临时部件并将部件合并到其中吗？ mysql是否用其他部分填充部分？那么，反转部分定义是否更好？例如：

ALTER TABLE mytable将分区p201903，p_first重新组织为（分区p_first值小于（TO_DAYS（'2019-04-01'））；

---

感谢您的回答

重新组织

将所有数据从源分区复制到目标分区。由于首先涉及

p_

并且该分区很大，因此需要很长时间，并锁定表

从另一个角度来看…MySQL“很安全”。但是通过必要数据的完整副本创建新分区，如果发生崩溃，旧分区是完整的。相反，如果它试图“合并”分区，崩溃可能会导致表损坏。安全性（和简单性）优于速度

不要不断地添加到这个巨大的分区中，而是添加到第二个分区中。或者，把它想象成每年构建一次分区。更具体地说，先别管

p_

，然后将

p201904

添加到

p201903

。下个月，将

p201905

添加到

p201903

。在年底，切换到“更好”的分区中收集2020年12个月的

p2020

命名约定等

十年后，您将有大约18个分区；这并不“糟糕”，并且您将看到正常操作中的差别很小，因为18个分区而不是8个分区

…用于获取上个月的数据

---

仅当您扫描整个月的分区时。让我看看您每月分区的好处。在几乎所有情况下，分区都不会提供性能好处。可能需要更改索引，才能使非分区表比分区表工作得更快或更快。

感谢您的帮助答案。分区按月非常有用，因为索引的大小是数据的2倍。这个表上有很多列，对它的查询非常多样化。一些分区查询可以在5分钟内执行，但如果没有它，则需要9小时。所以，如果我理解你的答案，我的第二个alter查询一定比第一个快？@user634062-“9小时”--听起来像是缺少了一个综合索引。即使是“5分钟”也值得一看。@user634062-创建新月份的

ALTER

应该在需要它之前完成。也就是说，

p\u future

应该保持为空（除非出现问题并且创建新分区失败）.我的目的是关于零件选择的意义

ALTER…p_first，p20190

，而不是

ALTER…p20190，p_first