Partitioning-related clauses for
TABLE can be used with partitioned tables for
repartitioning, for adding, dropping, discarding, importing,
merging, and splitting partitions, and for performing
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 14.1.18, “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;
MySQL 5.7.1 and later supports an
[SUB]PARTITION BY [LINEAR] KEY.
ALGORITHM=1causes the server to use the same key-hashing functions as MySQL 5.1 when computing the placement of rows in partitions;
ALGORITHM=2means that the server employs the key-hashing functions implemented and used by default for new
KEYpartitioned 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 using
ALGORITHM=2. This option is intended for use chiefly when upgrading or downgrading
[LINEAR] KEYpartitioned tables between MySQL 5.1 and later MySQL versions, or for creating tables partitioned by
LINEAR KEYon a MySQL 5.5 or later server which can be used on a MySQL 5.1 server.
To upgrade a
KEYpartitioned table that was created in MySQL 5.1, first execute
SHOW CREATE TABLEand note the exact columns and number of partitions shown. Now execute an
ALTER TABLEstatement using exactly the same column list and number of partitions as in the
CREATE TABLEstatement, while adding
ALGORITHM=2immediately following the
PARTITION BYkeywords. (You should also include the
LINEARkeyword if it was used for the original table definition.) An example from a session in the mysql client is shown here:
SHOW CREATE TABLE p\G*************************** 1. row *************************** Table: p Create Table: CREATE TABLE `p` ( `id` int(11) NOT NULL AUTO_INCREMENT, `cd` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 /*!50100 PARTITION BY LINEAR KEY (id) PARTITIONS 32 */ 1 row in set (0.00 sec) mysql>
ALTER TABLE pPARTITION BY LINEAR KEY ALGORITHM=2 (id) PARTITIONS 32
;Query OK, 0 rows affected (5.34 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>
SHOW CREATE TABLE p\G*************************** 1. row *************************** Table: p Create Table: CREATE TABLE `p` ( `id` int(11) NOT NULL AUTO_INCREMENT, `cd` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 /*!50100 PARTITION BY LINEAR KEY (id) PARTITIONS 32 */ 1 row in set (0.00 sec)
Downgrading a table created using the default key-hashing used in MySQL 5.5 and later to enable its use by a MySQL 5.1 server is similar, except in this case you should use
ALGORITHM=1to force the table's partitions to be rebuilt using the MySQL 5.1 key-hashing functions. It is recommended that you not do this except when necessary for compatibility with a MySQL 5.1 server, as the improved
KEYhashing functions used by default in MySQL 5.5 and later provide fixes for a number of issues found in the older implementation.Note
A table upgraded by means of
ALTER TABLE ... PARTITION BY ALGORITHM=2 [LINEAR] KEY ...can no longer be used by a MySQL 5.1 server. (Such a table would need to be downgraded with
ALTER TABLE ... PARTITION BY ALGORITHM=1 [LINEAR] KEY ...before it could be used again by a MySQL 5.1 server.)
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 21.6.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 ADD PARTITIONsupports the same options as the clause of the same name for the
CREATE TABLEstatement. (See Section 14.1.18, “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));
ADD PARTITIONcan also be used with the
TABLESPACEclause to add a new partition to an existing general tablespace, to a file-per-table tablespace, or to the system tablespace.
ALTER TABLE t1 ADD PARTITION (PARTITION p4 VALUES LESS THAN (2015) TABLESPACE = `ts1`);
ALTER TABLE t1 ADD PARTITION (PARTITION p4 VALUES LESS THAN (2015) TABLESPACE = `innodb_file_per_table`);
ALTER TABLE t1 ADD PARTITION (PARTITION p4 VALUES LESS THAN (2015) TABLESPACE = `innodb_system`);Note
TABLESPACE =option is not defined, the
ALTER TABLE ... ADD PARTITIONoperation adds the partition to the table's default tablespace, which can be specified at the table level during
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
NDBstorage engine. See Section 21.3.1, “Management of RANGE and LIST Partitions”, and Section 20.1.6, “Known Limitations of NDB Cluster”.
DROP PARTITIONdo not currently support
IF [NOT] EXISTS.
DISCARD PARTITION ... TABLESPACEand
IMPORT PARTITION ... TABLESPACEoptions extend the Transportable Tablespace feature to individual
InnoDBtable partitions. Each
InnoDBtable partition has its own tablespace file (
.idbfile). The Transportable 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;
DISCARD PARTITION ... TABLESPACEand
IMPORT PARTITION ... TABLESPACEon subpartitioned tables, both partition and subpartition names are allowed. When a partition name is specified, subpartitions of that partition are included.
The Transportable Tablespace feature also supports copying or restoring partitioned
InnoDBtables (all partitions at once). For addition information about the Transportable Tablespace feature, see Section 15.7.6, “Copying File-Per-Table Tablespaces to Another Server”. For usage examples, see Section 22.214.171.124, “Transportable Tablespace Examples”.
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..
In MySQL 5.7, it is possible to delete rows from selected partitions using the
TRUNCATE PARTITIONoption. This option takes a comma-separated list of one or more partition names. For example, consider the table
t1as defined 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), PARTITION p3 VALUES LESS THAN (2003), PARTITION p4 VALUES LESS THAN (2007) );
To delete all rows from partition
p0, you can use the following statement:
ALTER TABLE t1 TRUNCATE PARTITION p0;
The statement just shown has the same effect as the following
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 complex
WHEREconditions if done with
DELETEstatements. For example, this statement deletes all rows from partitions
ALTER TABLE t1 TRUNCATE PARTITION p1, p3;
DELETEstatement is shown here:
DELETE FROM t1 WHERE (year_col >= 1991 AND year_col < 1995) OR (year_col >= 2003 AND year_col < 2007);
You can also use the
ALLkeyword in place of the list of partition names; in this case, the statement acts on all partitions in the table.
TRUNCATE PARTITIONmerely deletes rows; it does not alter the definition of the table itself, or of any of its partitions.Note
Prior to MySQL 5.7.2,
TRUNCATE PARTITIONdid not work with subpartitions (Bug #14028340, Bug #65184).
You can verify that the rows were dropped by checking the
INFORMATION_SCHEMA.PARTITIONStable, using a query such as this one:
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 't1';
TRUNCATE PARTITIONis supported only for partitioned tables that use the
MEMORYstorage engine. It also works on
BLACKHOLEtables (but has no effect). It is not supported for
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
To move a partition from one tablespace to another. For an example, see Moving Table Partitions Between Tablespaces Using ALTER TABLE.
This statement may also be used without the
option on tables that are automatically partitioned using
HASHpartitioning to force redistribution of data. (Currently, only
NDBtables are automatically partitioned in this way.) This is useful in MySQL Cluster 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
ALGORITHM=INPLACEoption; in other words, as shown here:
tableALGORITHM=INPLACE, REORGANIZE PARTITION;
You cannot perform other DDL concurrently with online table reorganization—that is, no other DDL statements can be issued while an
ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITIONstatement is executing. For more information about adding MySQL Cluster data nodes online, see Section 20.5.14, “Adding NDB Cluster Data Nodes Online”.
ALTER TABLE ... ALGORITHM=INPLACE, 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. Instead, you can use
ALTER TABLE ... ALGORITHM=INPLACE, MAX_ROWS=to increase the maximum number of rows for such a table; in this case,
ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITIONis not needed (and causes an error if executed). 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. The same is true with regard to subpartitions.
For more detailed information about and examples of
ALTER TABLE ... REORGANIZE PARTITIONstatements, see Section 21.3.1, “Management of RANGE and LIST Partitions”.
In MySQL 5.7, it is possible to exchange a table partition or subpartition with a table using the
ALTER TABLE ... EXCHANGE PARTITIONstatement—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.
For usage information and examples, see Section 21.3.3, “Exchanging Partitions and Subpartitions with Tables”.
Several additional options provide 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; see Section 14.7.2, “Table Maintenance Statements” for more information). 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 21.3.4, “Maintenance of Partitions”.
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 PARTITIONcauses 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 are not permitted for tables which are not partitioned.
REMOVE PARTITIONINGenables you to remove a table's partitioning without otherwise affecting the table or its data. This option can be combined with other
ALTER TABLEoptions such as those used to add, drop, or rename columns or indexes.
ALTER TABLEchanges the storage engine used by the table without affecting the partitioning.
In MySQL 5.7, when
ALTER TABLE ...
EXCHANGE PARTITION or
ALTER TABLE ...
TRUNCATE PARTITION is run against a partitioned table
MyISAM (or another
storage engine that makes use of table-level locking), only
those partitions that are actually read from are locked. (This
does not apply to partitioned tables using a storage enginethat
employs row-level locking, such as
Section 21.6.4, “Partitioning and Locking”.
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.
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
partitions. For more information, see
Section 126.96.36.199, “ALTER TABLE Partition Operations”.
Only a single instance of any one of the following options can
be used in a given
REORGANIZE PARTITION, or
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;
Prior to MySQL 5.7.2,
operations were not supported for subpartitions. (Bug #14028340,
REBUILD operations are currently unsupported
for subpartitions. In MySQL 5.7.2, 5.7.3, and 5.7.4, the
REBUILD keyword was accepted with
subpartition names as valid syntax in
TABLE statements, even though it had no effect. In
REBUILD is expressly disallowed
with subpartitions, and causes
ALTER TABLE to
fail with an error if so used. (Bug #19075411, Bug #73130)
CHECK PARTITION and
PARTITION operations fail when the partition to be
checked or repaired contains any duplicate key errors.
MySQL 5.7.2 and 5.7.3 allowed alternative behavior that could be
ALTER IGNORE TABLE with the
corresponding options (Bug #16900947), which caused the
statement to behave as follows:
ALTER IGNORE TABLE ... REPAIR PARTITIONremoved from the partition all rows that could not be moved due to the presence of duplicate keys.
ALTER IGNORE TABLE ... CHECK PARTITIONwrote out the contents of all columns in the partitioning expression for each row in the partition in which a duplicate key violation was found.
This is no longer possible in MySQL 5.7.4 and later, where the
IGNORE keyword is no longer allowed (see
ALTER IGNORE TABLE).
For more information about these statements, see Section 21.3.4, “Maintenance of Partitions”.