A number of partitioning-related extensions to
ALTER TABLE were added in MySQL
5.1.5. These can be used with partitioned tables for
repartitioning, for adding, dropping, merging, and splitting
partitions, and for performing partitioning maintenance.
It is possible for an
statement to contain a
PARTITION BY or
REMOVE PARTITIONING clause in an addition to
other alter specifications, but the
REMOVE PARTITIONING clause
must be specified last after any other specifications. The
CHECK PARTITION, and
REPAIR PARTITION options cannot be combined
with other alter specifications in a single
TABLE, since the options just listed act on individual
Simply using a
ALTER TABLEon a partitioned table repartitions the table according to the partitioning scheme defined by the
partition_options. This clause always begins with
PARTITION BY, and follows the same syntax and other rules as apply to the
CREATE TABLE(see Section 13.1.17, “CREATE TABLE Syntax”, for more detailed information), 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 by
HASH, using the
idcolumn as the partitioning key, into 8 partitions by means of this statement:
ALTER TABLE t1 PARTITION BY HASH(id) PARTITIONS 8;
The table that results from using an
ALTER TABLE ... PARTITION BYstatement must follow the same rules as one created using
CREATE 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 in Section 18.5.1, “Partitioning Keys, Primary Keys, and Unique Keys”. The
CREATE TABLE ... PARTITION BYrules for specifying the number of partitions also apply to
ALTER TABLE ... PARTITION BY.
ALTER TABLE ... PARTITION BYbecame available in MySQL 5.1.6.
ALTER TABLE ADD PARTITIONsupports the same options as the clause of the same name for the
CREATE TABLEstatement. (See Section 13.1.17, “CREATE TABLE Syntax”, 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 partition
p3to this table for storing values less than
ALTER TABLE t1 ADD PARTITION (PARTITION p3 VALUES LESS THAN (2002));
DROP PARTITIONcan be used to drop one or more
LISTpartitions. This statement cannot be used with
KEYpartitions; instead, use
COALESCE PARTITION(see below). Any data that was stored in the dropped partitions named in the
partition_nameslist is discarded. For example, given the table
t1defined previously, you can drop the partitions named
p1as shown here:
ALTER TABLE t1 DROP PARTITION p0, p1;Note
DROP PARTITIONdoes not work with tables that use the
NDBCLUSTERstorage engine. See Section 18.3.1, “Management of RANGE and LIST Partitions”, and Section 17.1.6, “Known Limitations of MySQL Cluster”.
DROP PARTITIONdo not currently support
IF [NOT] EXISTS.
Renames of partitioned table are supported. You can rename individual partitions indirectly using
ALTER TABLE ... REORGANIZE PARTITION; however, this operation makes a copy of the partition's data..
COALESCE PARTITIONcan be used with a table that is partitioned by
KEYto reduce the number of partitions by
number. Suppose that you have created table
t2using the following definition:
CREATE TABLE t2 ( name VARCHAR (30), started DATE ) PARTITION BY HASH( YEAR(started) ) PARTITIONS 6;
You can reduce the number of partitions used by
t2from 6 to 4 using the following statement:
ALTER TABLE t2 COALESCE PARTITION 2;
The data contained in the last
numberpartitions will be merged into the remaining partitions. In this case, partitions 4 and 5 will be 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 use
REORGANIZE PARTITION. This statement can be used in several ways:
To merge a set of partitions into a single partition. This can be done by naming several partitions in the
partition_nameslist and supplying a single definition for
To split an existing partition into several partitions. You can accomplish this by naming a single partition for
partition_namesand providing multiple
To change the ranges for a subset of partitions defined using
VALUES LESS THANor the value lists for a subset of partitions defined using
This statement may also be used without the
option on tables that are automatically partitioned using
HASHpartitioning to force redistribution of data. (Currently, only
NDBCLUSTERtables are automatically partitioned in this way.) This is useful in MySQL Cluster NDB 7.0 and later where, after you have added new MySQL Cluster data nodes online to an existing MySQL Cluster, you wish to redistribute existing MySQL Cluster table data to the new data nodes. In such cases, you should invoke the statement with the
ONLINEoption; in other words, as shown here:
ALTER ONLINE TABLE
You cannot perform other DDL concurrently with online table reorganization—that is, no other DDL statements can be issued while an
ALTER ONLINE TABLE ... REORGANIZE PARTITIONstatement is executing. For more information about adding MySQL Cluster data nodes online, see Section 17.5.13, “Adding MySQL Cluster Data Nodes Online”.
ALTER ONLINE TABLE ... REORGANIZE PARTITIONdoes not work with tables which were created using the
MAX_ROWSoption, because it uses the constant
MAX_ROWSvalue specified in the original
CREATE TABLEstatement to determine the number of partitions required, so no new partitions are created. Beginning with MySQL Cluster NDB 7.0.32 and MySQL Cluster NDB 7.1.21, you can use
ALTER ONLINE TABLE ... MAX_ROWS=to increase the maximum number of rows for the table; after this,
ALTER ONLINE TABLE ... REORGANIZE PARTITIONcan use this new, larger value to increase the number of partitions. The value of
rowsmust be greater than the value specified for
MAX_ROWSin the original
CREATE TABLEstatement for this to work.
Attempting to use
REORGANIZE PARTITIONwithout the
option on explicitly partitioned tables results in the error REORGANIZE PARTITION without parameters can only be used on auto-partitioned tables using HASH partitioning.
For partitions that have not been explicitly named, MySQL automatically provides the default names
p2, and so on. As of MySQL 5.1.7, the same is true with regard to subpartitions.
For more detailed information about and examples of
ALTER TABLE ... REORGANIZE PARTITIONstatements, see Section 18.3.1, “Management of RANGE and LIST Partitions”.
Several additional options were introduced in MySQL 5.1.5 for providing partition maintenance and repair functionality analogous to that implemented for nonpartitioned tables by statements such as
REPAIR TABLE(which are also supported for partitioned tables, beginning with MySQL 5.1.27—see note at the end of this item). These include
REBUILD PARTITION, and
REPAIR PARTITION. Each of these options takes a
partition_namesclause consisting of one or more names of partitions, separated by commas. The partitions must already exist in the table to be altered. You can also use the
ALLkeyword in place of
partition_names, in which case the statement acts on all partitions in the table. For more information and examples, see Section 18.3.3, “Maintenance of Partitions”.
Prior to MySQL 5.1.68, it was not safe to execute multiple concurrent
REBUILD TABLEoperations on partitioned tables, whether on the same or different tables. (Bug #14589559, Bug #66645)
Some MySQL storage engines, such as
InnoDB, do not support per-partition optimization. For a partitioned table using such a storage engine,
ALTER TABLE ... OPTIMIZE PARTITIONrebuilds the entire table. This is a known issue. Beginning with MySQL 5.1.68, running this statement on such a table causes the entire table to rebuilt and analyzed, and an appropriate warning to be issued. (Bug #11751825, Bug #42822)
To work around this problem, use the statements
ALTER TABLE ... REBUILD PARTITIONand
ALTER TABLE ... ANALYZE PARTITIONinstead.
OPTIMIZE PARTITION, and
REPAIR PARTITIONoptions were disabled in MySQL 5.1.24, and re-enabled in MySQL 5.1.27. (Bug #20129) They are not supported for tables which are not partitioned; beginning with MySQL 5.1.31, they are not permitted for such tables.
Beginning with MySQL 5.1.27, you can use the statements
OPTIMIZE TABLE, and
REPAIR TABLEon partitioned tables. See Section 13.7.2, “Table Maintenance Statements”, for more information.
REMOVE PARTITIONINGwas introduced in MySQL 5.1.8 for the purpose of removing a table's partitioning without otherwise affecting the table or its data. (Previously, this was done using the
ENGINEoption.) This option can be combined with other
ALTER TABLEoptions such as those used to add, drop, or rename columns or indexes.
In MySQL 5.1.7 and earlier, using the
ALTER TABLEcaused any partitioning that a table might have had to be removed. Beginning with MySQL 5.1.8, this option merely changes the storage engine used by the table and no longer affects partitioning in any way.
Only a single instance of any one of the following options can
be used in a given
For example, the following two statements are invalid:
ALTER TABLE t1 ANALYZE PARTITION p1, ANALYZE PARTITION p2; ALTER TABLE t1 ANALYZE PARTITION p1, CHECK PARTITION p2;
In the first case, you can analyze partitions
p2 of table
t1 concurrently using a single statement with
ANALYZE PARTITION option that lists
both of the partitions to be analyzed, like this:
ALTER TABLE t1 ANALYZE PARTITION p1, p2;
In the second case, it is not possible to perform
operations on different partitions of the same table
concurrently. Instead, you must issue two separate statements,
ALTER TABLE t1 ANALYZE PARTITION p1; ALTER TABLE t1 CHECK PARTITION p2;
operations are not allowed with subpartitions.