MySQL:为 future 日期添加分区

Question

我正在尝试使用其 created 字段对现有表(包含现有数据)进行分区。为遥远 future 的日期创建许多分区是否合适？这有什么缺点吗？

由于我表的现有 PK 只是 id，我将其更改为包含 created 字段，以便我可以按 RANGE 对其进行分区:

ALTER TABLE orders DROP PRIMARY KEY, ADD PRIMARY KEY(id, created);

添加分区到 2018 年底:

ALTER TABLE orders PARTITION BY RANGE (TO_DAYS(created))(
    PARTITION p001 VALUES LESS THAN (0),
    PARTITION p002 VALUES LESS THAN (TO_DAYS('2015-05-01')),
    PARTITION p003 VALUES LESS THAN (TO_DAYS('2015-09-01')),
    PARTITION p004 VALUES LESS THAN (TO_DAYS('2016-01-01')),
    PARTITION p005 VALUES LESS THAN (TO_DAYS('2016-05-01')),
    PARTITION p006 VALUES LESS THAN (TO_DAYS('2016-09-01')),
    PARTITION p007 VALUES LESS THAN (TO_DAYS('2017-01-01')),
    PARTITION p008 VALUES LESS THAN (TO_DAYS('2017-05-01')),
    PARTITION p009 VALUES LESS THAN (TO_DAYS('2017-09-01')),
    PARTITION p010 VALUES LESS THAN (TO_DAYS('2018-01-01')),
    PARTITION p011 VALUES LESS THAN (TO_DAYS('2018-05-01')),
    PARTITION p012 VALUES LESS THAN (TO_DAYS('2018-09-01')),
    PARTITION p013 VALUES LESS THAN (TO_DAYS('2019-01-01')),
    PARTITION pmax VALUES LESS THAN MAXVALUE
)

这样可以吗？还是等到年底再申请明年的新分区会好得多？

Answer 1

• 您希望通过添加分区获得什么优势？我问是因为没有性能提升，至少没有其他更改。

• 您需要在所有 PRIMARY 和 UNIQUE 键中包含“分区键”created。通常最好放在最后。 (你做到了。)

• 由于许多操作会打开所有分区(是的，这可能是一个“错误”)，拥有大量“ future ”分区效率低下。

• 我建议一个表中有 20-50 个分区。少是无用的；更多会导致其他低效率。

在我的Partition Maintenance blog我列出了仅有的 4 个分区用例，并讨论了如何清除旧分区以及何时添加新分区。