MySQL：爲未來日期添加分區

我試圖使用其created字段對現有表（使用現有數據）進行分區。在未來的日期創建多個分區是否正確？這有什麼缺點嗎？MySQL：爲未來日期添加分區

由於我的表現有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 
)

可以嗎？或者等到今年年底才能爲明年申請新的分區好得多？

來源

2015-08-19 enchance

您希望通過添加分區獲得什麼優勢？我問，因爲沒有性能收益，至少不是沒有其他變化。
您需要在所有的PRIMARY和UNIQUE鍵中包含「分區鍵」created。通常最好把它放在最後。（你這樣做。）
由於許多操作打開所有分區（是的，這可能是一個'錯誤'），有很多'未來'分區是低效的。
我推薦20-50個分區在一個表中。少就是無用;更多導致其他低效率。

在我Partition Maintenance blog我列出分區中只有4個用例，再加上討論如何清除舊的分區，當增加新的。

來源

2015-08-19 18:19:53

這沒有回答任何問題 – user1143669

@ user1143669 - 這個問題似乎是關於創建大量'未來'分區。答案是「不」，有些原因不適用。相反，只創建一個，但不打算填充它;而是在夜間「構建明天的分區」失敗時保存它。 –

MySQL：爲未來日期添加分區

回答

相關問題