Movatterモバイル変換

Simply using apartition_options clause withALTER TABLE on a partitioned table repartitions the table according to the partitioning scheme defined by thepartition_options. This clause always begins withPARTITION BY, and follows the same syntax and other rules as apply to thepartition_options clause forCREATE TABLE (for more detailed information, seeSection 15.1.24, “CREATE TABLE Statement”), and can also be used to partition an existing table that is not already partitioned. For example, consider a (nonpartitioned) table defined as shown here:

CREATE TABLE t1 (    id INT,    year_col INT);

This table can be partitioned byHASH, using theid column as the partitioning key, into 8 partitions by means of this statement:

ALTER TABLE t1    PARTITION BY HASH(id)    PARTITIONS 8;

MySQL supports anALGORITHM option with[SUB]PARTITION BY [LINEAR] KEY.ALGORITHM=1 causes the server to use the same key-hashing functions as MySQL 5.1 when computing the placement of rows in partitions;ALGORITHM=2 means that the server employs the key-hashing functions implemented and used by default for newKEY partitioned tables in MySQL 5.5 and later. (Partitioned tables created with the key-hashing functions employed in MySQL 5.5 and later cannot be used by a MySQL 5.1 server.) Not specifying the option has the same effect as usingALGORITHM=2. This option is intended for use chiefly when upgrading or downgrading[LINEAR] KEY partitioned tables between MySQL 5.1 and later MySQL versions, or for creating tables partitioned byKEY orLINEAR KEY on a MySQL 5.5 or later server which can be used on a MySQL 5.1 server.

The table that results from using anALTER TABLE ... PARTITION BY statement must follow the same rules as one created usingCREATE TABLE ... PARTITION BY. This includes the rules governing the relationship between any unique keys (including any primary key) that the table might have, and the column or columns used in the partitioning expression, as discussed inSection 26.6.1, “Partitioning Keys, Primary Keys, and Unique Keys”. TheCREATE TABLE ... PARTITION BY rules for specifying the number of partitions also apply toALTER TABLE ... PARTITION BY.

Thepartition_definition clause forALTER TABLE ADD PARTITION supports the same options as the clause of the same name for theCREATE TABLE statement. (SeeSection 15.1.24, “CREATE TABLE Statement”, for the syntax and description.) Suppose that you have the partitioned table created as shown here:

CREATE TABLE t1 (    id INT,    year_col INT)PARTITION BY RANGE (year_col) (    PARTITION p0 VALUES LESS THAN (1991),    PARTITION p1 VALUES LESS THAN (1995),    PARTITION p2 VALUES LESS THAN (1999));

You can add a new partitionp3 to this table for storing values less than2002 as follows:

ALTER TABLE t1 ADD PARTITION (PARTITION p3 VALUES LESS THAN (2002));

DROP PARTITION can be used to drop one or moreRANGE orLIST partitions. This statement cannot be used withHASH orKEY partitions; instead, useCOALESCE PARTITION (see later in this section). Any data that was stored in the dropped partitions named in thepartition_names list is discarded. For example, given the tablet1 defined previously, you can drop the partitions namedp0 andp1 as shown here:

ALTER TABLE t1 DROP PARTITION p0, p1;

ADD PARTITION andDROP PARTITION do not currently supportIF [NOT] EXISTS.

TheDISCARD PARTITION ... TABLESPACE andIMPORT PARTITION ... TABLESPACE options extend theTransportable Tablespace feature to individualInnoDB table partitions. EachInnoDB table partition has its own tablespace file (.ibd file). TheTransportable Tablespace feature makes it easy to copy the tablespaces from a running MySQL server instance to another running instance, or to perform a restore on the same instance. Both options take a comma-separated list of one or more partition names. For example:

ALTER TABLE t1 DISCARD PARTITION p2, p3 TABLESPACE;

ALTER TABLE t1 IMPORT PARTITION p2, p3 TABLESPACE;

When runningDISCARD PARTITION ... TABLESPACE andIMPORT PARTITION ... TABLESPACE on subpartitioned tables, both partition and subpartition names are allowed. When a partition name is specified, subpartitions of that partition are included.

TheTransportable Tablespace feature also supports copying or restoring partitionedInnoDB tables. For more information, seeSection 17.6.1.3, “Importing InnoDB Tables”.

Renames of partitioned tables are supported. You can rename individual partitions indirectly usingALTER TABLE ... REORGANIZE PARTITION; however, this operation copies the partition's data.

To delete rows from selected partitions, use theTRUNCATE PARTITION option. This option takes a list of one or more comma-separated partition names. Consider the tablet1 created by this statement:

CREATE TABLE t1 (    id INT,    year_col INT)PARTITION BY RANGE (year_col) (    PARTITION p0 VALUES LESS THAN (1991),    PARTITION p1 VALUES LESS THAN (1995),    PARTITION p2 VALUES LESS THAN (1999),    PARTITION p3 VALUES LESS THAN (2003),    PARTITION p4 VALUES LESS THAN (2007));

To delete all rows from partitionp0, use the following statement:

ALTER TABLE t1 TRUNCATE PARTITION p0;

The statement just shown has the same effect as the followingDELETE statement:

DELETE FROM t1 WHERE year_col < 1991;

When truncating multiple partitions, the partitions do not have to be contiguous: This can greatly simplify delete operations on partitioned tables that would otherwise require very complexWHERE conditions if done withDELETE statements. For example, this statement deletes all rows from partitionsp1 andp3:

ALTER TABLE t1 TRUNCATE PARTITION p1, p3;

An equivalentDELETE statement is shown here:

DELETE FROM t1 WHERE    (year_col >= 1991 AND year_col < 1995)    OR    (year_col >= 2003 AND year_col < 2007);

If you use theALL keyword in place of the list of partition names, the statement acts on all table partitions.

TRUNCATE PARTITION merely deletes rows; it does not alter the definition of the table itself, or of any of its partitions.

To verify that the rows were dropped, check theINFORMATION_SCHEMA.PARTITIONS table, using a query such as this one:

SELECT PARTITION_NAME, TABLE_ROWS    FROM INFORMATION_SCHEMA.PARTITIONS    WHERE TABLE_NAME = 't1';

COALESCE PARTITION can be used with a table that is partitioned byHASH orKEY to reduce the number of partitions bynumber. Suppose that you have created tablet2 as follows:

CREATE TABLE t2 (    name VARCHAR (30),    started DATE)PARTITION BY HASH( YEAR(started) )PARTITIONS 6;

To reduce the number of partitions used byt2 from 6 to 4, use the following statement:

ALTER TABLE t2 COALESCE PARTITION 2;

The data contained in the lastnumber partitions is merged into the remaining partitions. In this case, partitions 4 and 5 are merged into the first 4 partitions (the partitions numbered 0, 1, 2, and 3).

To change some but not all the partitions used by a partitioned table, you can useREORGANIZE PARTITION. This statement can be used in several ways:

For more detailed information about and examples ofALTER TABLE ... REORGANIZE PARTITION statements, seeSection 26.3.1, “Management of RANGE and LIST Partitions”.

To exchange a table partition or subpartition with a table, use theALTER TABLE ... EXCHANGE PARTITION statement—that is, to move any existing rows in the partition or subpartition to the nonpartitioned table, and any existing rows in the nonpartitioned table to the table partition or subpartition.

Once one or more columns have been added to a partitioned table usingALGORITHM=INSTANT, it is no longer possible to exchange partitions with that table.

For usage information and examples, seeSection 26.3.3, “Exchanging Partitions and Subpartitions with Tables”.

Several options provide partition maintenance and repair functionality analogous to that implemented for nonpartitioned tables by statements such asCHECK TABLE andREPAIR TABLE (which are also supported for partitioned tables; for more information, seeSection 15.7.3, “Table Maintenance Statements”). These includeANALYZE PARTITION,CHECK PARTITION,OPTIMIZE PARTITION,REBUILD PARTITION, andREPAIR PARTITION. Each of these options takes apartition_names clause consisting of one or more names of partitions, separated by commas. The partitions must already exist in the target table. You can also use theALL keyword in place ofpartition_names, in which case the statement acts on all table partitions. For more information and examples, seeSection 26.3.4, “Maintenance of Partitions”.

InnoDB does not currently support per-partition optimization;ALTER TABLE ... OPTIMIZE PARTITION causes the entire table to rebuilt and analyzed, and an appropriate warning to be issued. (Bug #11751825, Bug #42822) To work around this problem, useALTER TABLE ... REBUILD PARTITION andALTER TABLE ... ANALYZE PARTITION instead.

TheANALYZE PARTITION,CHECK PARTITION,OPTIMIZE PARTITION, andREPAIR PARTITION options are not supported for tables which are not partitioned.

REMOVE PARTITIONING enables you to remove a table's partitioning without otherwise affecting the table or its data. This option can be combined with otherALTER TABLE options such as those used to add, drop, or rename columns or indexes.

Using theENGINE option withALTER TABLE changes the storage engine used by the table without affecting the partitioning. The target storage engine must provide its own partitioning handler. Only theInnoDB andNDB storage engines have native partitioning handlers.