Subpartitioning—also known as
        composite
        partitioning—is the further division of each
        partition in a partitioned table. Consider the following
        CREATE TABLE statement:
      
CREATE TABLE ts (id INT, purchased DATE)
    PARTITION BY RANGE( YEAR(purchased) )
    SUBPARTITION BY HASH( TO_DAYS(purchased) )
    SUBPARTITIONS 2 (
        PARTITION p0 VALUES LESS THAN (1990),
        PARTITION p1 VALUES LESS THAN (2000),
        PARTITION p2 VALUES LESS THAN MAXVALUE
    );
        Table ts has 3 RANGE
        partitions. Each of these
        partitions—p0, p1,
        and p2—is further divided into 2
        subpartitions. In effect, the entire table is divided into
        3 * 2 = 6 partitions. However, due to the
        action of the PARTITION BY RANGE clause, the
        first 2 of these store only those records with a value less than
        1990 in the purchased column.
      
        It is possible to subpartition tables that are partitioned by
        RANGE or LIST.
        Subpartitions may use either HASH or
        KEY partitioning. This is also known as
        composite partitioning.
          SUBPARTITION BY HASH and
          SUBPARTITION BY KEY generally follow the
          same syntax rules as PARTITION BY HASH and
          PARTITION BY KEY, respectively. An
          exception to this is that SUBPARTITION BY
          KEY (unlike PARTITION BY KEY)
          does not currently support a default column, so the column
          used for this purpose must be specified, even if the table has
          an explicit primary key. This is a known issue which we are
          working to address; see
          Issues with subpartitions, for
          more information and an example.
        It is also possible to define subpartitions explicitly using
        SUBPARTITION clauses to specify options for
        individual subpartitions. For example, a more verbose fashion of
        creating the same table ts as shown in the
        previous example would be:
      
CREATE TABLE ts (id INT, purchased DATE)
    PARTITION BY RANGE( YEAR(purchased) )
    SUBPARTITION BY HASH( TO_DAYS(purchased) ) (
        PARTITION p0 VALUES LESS THAN (1990) (
            SUBPARTITION s0,
            SUBPARTITION s1
        ),
        PARTITION p1 VALUES LESS THAN (2000) (
            SUBPARTITION s2,
            SUBPARTITION s3
        ),
        PARTITION p2 VALUES LESS THAN MAXVALUE (
            SUBPARTITION s4,
            SUBPARTITION s5
        )
    );Some syntactical items of note are listed here:
- Each partition must have the same number of subpartitions. 
- If you explicitly define any subpartitions using - SUBPARTITIONon any partition of a partitioned table, you must define them all. In other words, the following statement fails:- CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) SUBPARTITION BY HASH( TO_DAYS(purchased) ) ( PARTITION p0 VALUES LESS THAN (1990) ( SUBPARTITION s0, SUBPARTITION s1 ), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE ( SUBPARTITION s2, SUBPARTITION s3 ) );- This statement would still fail even if it used - SUBPARTITIONS 2.
- Each - SUBPARTITIONclause must include (at a minimum) a name for the subpartition. Otherwise, you may set any desired option for the subpartition or allow it to assume its default setting for that option.
- Subpartition names must be unique across the entire table. For example, the following - CREATE TABLEstatement is valid:- CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) SUBPARTITION BY HASH( TO_DAYS(purchased) ) ( PARTITION p0 VALUES LESS THAN (1990) ( SUBPARTITION s0, SUBPARTITION s1 ), PARTITION p1 VALUES LESS THAN (2000) ( SUBPARTITION s2, SUBPARTITION s3 ), PARTITION p2 VALUES LESS THAN MAXVALUE ( SUBPARTITION s4, SUBPARTITION s5 ) );