Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

17.2.4. KEY Partitioning

Partitioning by key is similar to partitioning by hash, except that where hash partitioning employs a user-defined expression, the hashing function for key partitioning is supplied by the MySQL server. MySQL Cluster uses MD5() for this purpose; for tables using other storage engines, the server employs its own internal hashing function which is based on the same algorithm as PASSWORD().

The syntax rules for CREATE TABLE ... PARTITION BY KEY are similar to those for creating a table that is partitioned by hash. The major differences are that:

  • KEY is used rather than HASH.

  • KEY takes only a list of one or more column names. Beginning with MySQL 5.1.5, the column or columns used as the partitioning key must comprise part or all of the table's primary key, if the table has one.

    Beginning with MySQL 5.1.6, KEY takes a list of zero or more column names. Where no column name is specified as the partitioning key, the table's primary key is used. For example, the following CREATE TABLE statement is valid in MySQL 5.1.6 or later:

    CREATE TABLE k1 (   
        id INT NOT NULL PRIMARY KEY,   
        name VARCHAR(20) 
    ) 
    PARTITION BY KEY() 
    PARTITIONS 2;
    

    In this case, the partitioning key is the id column, even though it is not shown in the output of SHOW CREATE TABLE or in the PARTITION_EXPRESSION column of the INFORMATION_SCHEMA.PARTITIONS table.

    Note: Also beginning with MySQL 5.1.6, tables using the NDB Cluster storage engine are implicitly partitioned by KEY, again using the table's primary key as the partitioning key. For example, consider a table created using the following statement:

    CREATE TABLE kndb (   
        id INT NOT NULL PRIMARY KEY,   
        name VARCHAR(20) NOT NULL 
    )
    ENGINE=NDBCLUSTER;
    

    Although there is no PARTITION BY clause in the table creation statement, the output of SHOW CREATE TABLE kndb is as shown here:

    CREATE TABLE `kndb` (   
        `id` int(11) NOT NULL,   
        `name` varchar(20) NOT NULL.
        PRIMARY KEY  (`id`) 
    )
    ENGINE=ndbcluster DEFAULT CHARSET=latin1 PARTITION BY KEY ();
    

    In the event that the Cluster table has no explicit primary key, the “hidden” primary key generated by the NDB storage engine for each Cluster table is used as the partitioning key.

    Important: For a key-partitioned table using any MySQL storage engine other than NDB CLuster, you cannot execute an ALTER TABLE DROP PRIMARY KEY, as doing so generates the error ERROR 1466 (HY000): Field in list of fields for partition function not found in table. This is not an issue for MySQL CLuster tables which are partitioned by KEY; in such cases, the table is reorganized using the “hidden” primary key as the table's new partitioning key. See Chapter 16, MySQL Cluster.

It is also possible to partition a table by linear key. Here is a simple example:

CREATE TABLE tk (
    col1 INT NOT NULL,
    col2 CHAR(5),
    col3 DATE
) 
PARTITION BY LINEAR KEY (col1)
PARTITIONS 3;

Using LINEAR has the same effect on KEY partitioning as it does on HASH partitioning, with the partition number being derived using a powers-of-two algorithm rather than modulo arithmetic. See Section 17.2.3.1, “LINEAR HASH Partitioning”, for a description of this algorithm and its implications.


 
 
  Published under the terms of the GNU General Public License Design by Interspire