Author: jstephens
Date: 2006-01-24 17:14:16 +0100 (Tue, 24 Jan 2006)
New Revision: 1018
Log:
New wrinkles in KEY partitioning and affects for NDBCluster tables.
(Bug #16736, discussion of same with Mikael and Jeb.)
Modified:
trunk/refman-5.1/ndbcluster.xml
trunk/refman-5.1/partitioning.xml
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-24 12:50:05 UTC (rev 1017)
+++ trunk/refman-5.1/ndbcluster.xml 2006-01-24 16:14:16 UTC (rev 1018)
@@ -72,7 +72,7 @@
<listitem>
<para>
- The MySQL Cluster forum:
+ The MySQL Cluster Forum:
<ulink url="&base-url-forum-list;?25"/>.
</para>
</listitem>
@@ -10588,6 +10588,17 @@
<xref linkend="partitioning-management-range-list"/> and
<xref linkend="alter-table"/>.
</para>
+
+ <para>
+ As of MySQL 5.1.6, all Cluster tables are by default
+ partitioned by <literal>KEY</literal> using the table's
+ primary key as the partitioning key. If no primary key is
+ explicitly set for the table, then the
+ <quote>hidden</quote> primary key automatically created by
+ the <literal>NDB</literal> storage engine is used instead.
+ For additional discussion of these and related issues, see
+ <xref linkend="partitioning-key"/>.
+ </para>
</listitem>
</itemizedlist>
Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml 2006-01-24 12:50:05 UTC (rev 1017)
+++ trunk/refman-5.1/partitioning.xml 2006-01-24 16:14:16 UTC (rev 1018)
@@ -1390,12 +1390,107 @@
<para>
The syntax rules for <literal>CREATE TABLE ... PARTITION BY
KEY</literal> are similar to those for creating a table that is
- partitioned by hash. The only differences are that you use
- <literal>KEY</literal> rather than <literal>HASH</literal>, and
- that <literal>KEY</literal> takes only a list of one or more
- column names.
+ partitioned by hash. The major differences are that:
</para>
-
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>KEY</literal> is used rather than
+ <literal>HASH</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>KEY</literal> 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.
+ </para>
+
+ <para>
+ Beginning with MySQL 5.1.6, <literal>KEY</literal> 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 <literal>CREATE
+ TABLE</literal> statement is valid in MySQL 5.1.6 or
+ later:
+ </para>
+
+<programlisting>
+CREATE TABLE k1 (
+ id INT NOT NULL PRIMARY KEY,
+ name VARCHAR(20)
+)
+PARTITION BY KEY()
+PARTITIONS 2;
+</programlisting>
+
+ <para>
+ In this case, the partitioning key is the
+ <literal>id</literal> column, even though it is not shown in
+ the output of <literal>SHOW CREATE TABLE</literal> or in the
+ <literal>PARTITION_EXPRESSION</literal> column of the
+ <literal>INFORMATION_SCHEMA.PARTITIONS</literal> table.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Also beginning with
+ MySQL 5.1.6, tables using the <literal>NDB Cluster</literal>
+ storage engine are implicitly partitioned by
+ <literal>KEY</literal>, again using the table's primary key
+ as the partitioning key. For example, consider a table
+ created using the following statement:
+ </para>
+
+<programlisting>
+CREATE TABLE kndb (
+ id INT NOT NULL PRIMARY KEY,
+ name VARCHAR(20) NOT NULL
+)
+ENGINE=NDBCLUSTER;
+</programlisting>
+
+ <para>
+ Although there is no <literal>PARTITION BY</literal> clause
+ in the table creation statement, the output of <literal>SHOW
+ CREATE TABLE kndb</literal> is as shown here:
+ </para>
+
+<programlisting>
+CREATE TABLE `kndb` (
+ `id` int(11) NOT NULL,
+ `name` varchar(20) NOT NULL.
+ PRIMARY KEY (`id`)
+)
+ENGINE=ndbcluster DEFAULT CHARSET=latin1 PARTITION BY KEY ();
+</programlisting>
+
+ <para>
+ In the event that the Cluster table has no explicit primary
+ key, the <quote>hidden</quote> primary key generated by the
+ <literal>NDB</literal> storage engine for each Cluster table
+ is used as the partitioning key.
+ </para>
+
+ <para>
+ <emphasis role="bold">Important</emphasis>: For a
+ key-partitioned table using any MySQL storage engine other
+ than <literal>NDB CLuster</literal>, you cannot execute an
+ <literal>ALTER TABLE DROP PRIMARY KEY</literal>, as doing so
+ generates the error <errortext>ERROR 1466 (HY000): Field in
+ list of fields for partition function not found in
+ table</errortext>. This is not an issue for MySQL CLuster
+ tables which are partitioned by <literal>KEY</literal>; in
+ such cases, the table is reorganized using the
+ <quote>hidden</quote> primary key as the table's new
+ partitioning key. See <xref linkend="ndbcluster"/>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+
<indexterm>
<primary>partitioning by linear key</primary>
</indexterm>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1018 - trunk/refman-5.1 | jon | 24 Jan |
