MYSQL中的子分區

我需要明智地分區表日期，然後這個分區需要通過用戶ID進行子分區。我分區表如下圖所示：MYSQL中的子分區

ALTER TABLE sentbox1 PARTITION BY RANGE(to_days(CreatedDateTime))(
PARTITION p20161130 VALUES LESS THAN (to_days('2016-11-30')), 
PARTITION p20161201 VALUES LESS THAN (to_days('2016-12-01')) 
);

現在，如何通過用戶ID添加子分區到分區的p20161130'和「p20161201」。

來源

2016-11-29 dharmesh parmar

我測試了在MySQL 8.0.0-DMR：

ALTER TABLE sentbox1 
PARTITION BY RANGE(to_days(CreatedDateTime)) 
SUBPARTITION BY HASH(userid) 
SUBPARTITIONS 4 (
    PARTITION p20161130 VALUES LESS THAN (to_days('2016-11-30')), 
    PARTITION p20161201 VALUES LESS THAN (to_days('2016-12-01')) 
);

注意，子分區僅適用於HASH或KEY作爲分區方法。

查看https://dev.mysql.com/doc/refman/5.7/en/partitioning-subpartitions.html瞭解更多信息。從裏克

回覆評論：

@RickJames，我想你知道，完全取決於查詢一個運行是否符合分區和子分區對齊。如果您的查詢邏輯導致查詢跨越子分區，則不會帶來任何好處。

我確認分區修剪需要注意子分區鍵上的條件。

當我把一個條件僅在主要分區鍵，因此它必須掃描該分區的所有子分區：

mysql> explain partitions select * from sentbox1 
    where createddatetime = from_days(736663) \G 
*************************** 1. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: sentbox1 
    partitions: p20161201_p20161201sp0, 
       p20161201_p20161201sp1, 
       p20161201_p20161201sp2, 
       p20161201_p20161201sp3 
     type: ALL 
possible_keys: NULL 
      key: NULL 
     key_len: NULL 
      ref: NULL 
     rows: 1 
    filtered: 100.00 
     Extra: Using where

當我另外指定的userid（子分區鍵）的條件，我們可以看到要檢查的子部分的減少子集：

mysql> explain partitions select * from sentbox1 
    where createddatetime = from_days(736663) and userid=3\G 
*************************** 1. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: sentbox1 
    partitions: p20161201_p20161201sp3 
     type: ALL 
possible_keys: NULL 
      key: NULL 
     key_len: NULL 
      ref: NULL 
     rows: 1 
    filtered: 100.00 
     Extra: Using where

來源

2016-11-29 06:47:17

您測試了它，但您是否確定對HASH或SUBPARTITION有任何性能優勢？（我把這當成是對你的挑戰，比爾。） –

有時，問題的答案是「不要」。我還沒有找到任何用於SUBPARTITION。請解釋您認爲這會有所幫助的用例。

特別是，分區本身不會提供任何性能優勢。

BY RANGE(TO_DAYS(..))的常見用例是當您需要刪除「舊」數據時。做DROP PARTITION明顯比DELETE更有效率。你有這種情況嗎？如果是這樣，有SUBPARTITIONs不以我知道的任何方式幫助。

同時，我發現沒有用例HASH。當然，它可能會在userid上修剪，但修剪並不比在複合索引開始時有userid更好。而且可能會更糟。

More discussion of Partitioning。

來源

2016-11-29 18:41:32

MYSQL中的子分區

回答

相關問題