【发布时间】:2021-12-30 16:48:53
【问题描述】:
我想向已经分区的表添加新分区,如果我们使用 REORGANIZE,这很简单,因为它的回答是 here,但在我的情况下,我在 p_max 分区中有大量数据,这将永远用于 REORGANIZE。
所以,我想在不重新组织当前 p_max 分区的情况下将新分区添加到已经分区的表中,以便立即添加新分区。
【问题讨论】:
标签: mysql sql mariadb partitioning
我想向已经分区的表添加新分区,如果我们使用 REORGANIZE,这很简单,因为它的回答是 here,但在我的情况下,我在 p_max 分区中有大量数据,这将永远用于 REORGANIZE。
所以,我想在不重新组织当前 p_max 分区的情况下将新分区添加到已经分区的表中,以便立即添加新分区。
【问题讨论】:
标签: mysql sql mariadb partitioning
简单:总是让p_max 为空。我喜欢称它为future。然后,就在之前你需要p_3,将future分成p_3和future。该分区中没有数据,因此速度很快。
详情:http://mysql.rjweb.org/doc.php/partitionmaint#high_level_view_of_the_code
“为什么”:http://mysql.rjweb.org/doc.php/partitionmaint#why_
(两者都在同一篇关于 MySQL 分区的论文中。)
更多
你是什么PARTITIONing BY ...? (如果我知道你的“BY ...”,我就可以不那么含糊了。)
我能推荐的最好的方法是花足够的停机时间
ALTER TABLE ..
REORGANIZE p_max to
p_3 ... LESS THAN (...),
p_4 ... LESS THAN (...),
p_5 ... LESS THAN (...),
p_max ... LESS THAN MAXVALUE; -- empty
拥有 p_4 和 p_5 可能有用也可能没用。将数据分解为您建立的任何模式(例如,每月)会更“干净”,但它可能不会提供任何好处。
请注意,这可能会留下一个新的 p_max 为空。然后,未来的重组会很快。
正如我在博客中指出的那样,p_max应该始终为空,但如果它不小心填满了数据,您不会丢失数据。相反,重组会更慢(正如您所观察到的那样)。
B 计划 这可能是你最大的希望。
请参阅 Percona 工具包。它有pt-online-schema-update,我认为它将处理更改分区表。
【讨论】: