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中的子分区

回答

相关问题