Author: jstephens
Date: 2007-05-17 01:54:20 +0200 (Thu, 17 May 2007)
New Revision: 6507
Log:
More edits to Cluster Limitations (5.1 version)...
Modified:
trunk/refman-5.1/mysql-cluster-limitations-working.xml
Modified: trunk/refman-5.1/mysql-cluster-limitations-working.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations-working.xml 2007-05-16 19:40:07 UTC (rev 6506)
+++ trunk/refman-5.1/mysql-cluster-limitations-working.xml 2007-05-16 23:54:20 UTC (rev 6507)
Changed blocks: 6, Lines Added: 417, Lines Deleted: 392; 34499 bytes
@@ -87,10 +87,10 @@
<listitem>
<formalpara>
- <title><literal>NDB</literal> tables and indexes</title>
+ <title>Indexes and keys in <literal>NDB</literal> tables</title>
<para>
- Indexes on MySQL Cluster tables are subject to the
+ Keys and indexes on MySQL Cluster tables are subject to the
following limitations:
<itemizedlist>
<listitem>
@@ -122,6 +122,43 @@
primary key, unique key, or index.
</para>
</listitem>
+
+ <listitem>
+ <formalpara>
+ <title>Duplicate keys</title>
+ <para>
+ A duplicate key error returns the error message
+ <errortext>ERROR 23000: Can't write; duplicate key in
+ table
+ '<replaceable>tbl_name</replaceable>'</errortext>.
+ </para>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title><literal>AUTO_INCREMENT</literal> columns</title>
+ <para>
+ Like other MySQL storage engines, the
+ <literal>NDB</literal> storage engine can handle a
+ maximum of one <literal>AUTO_INCREMENT</literal>
+ column per table. However, in the case of a Cluster
+ table with no explicit primary key, an
+ <literal>AUTO_INCREMENT</literal> column is
+ automatically defined and used as a
+ <quote>hidden</quote> primary key. For this reason,
+ you cannot define a table that has an explicit
+ <literal>AUTO_INCREMENT</literal> column unless that
+ column is also declared using the <literal>PRIMARY
+ KEY</literal> option. Attempting to create a table with an
+ <literal>AUTO_INCREMENT</literal> column that is not
+ the table's primary key, and using the
+ <literal>NDB</literal> storage engine, fails with an
+ error.
+ </para>
+ </formalpara>
+ </listitem>
+
</itemizedlist>
</para>
@@ -229,40 +266,17 @@
</section>
<section id="mysql-cluster-limitations-limits">
- <title>Deviations from Standard MySQL Limits</title>
+ <title>Limits and Differences from Standard MySQL Limits</title>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>and differences from standard MySQL limits</secondary>
+ </indexterm>
<para>
-
- </para>
- </section>
-
-
- <itemizedlist>
+ In this section, we list limits found in MySQL Cluster that either
+ differ from limits found in, or that are not found in, standard MySQL.
+ <itemizedlist>
- <listitem>
-
- <para>
- <emphasis role="bold">Noncompliance in syntax</emphasis>
- (resulting in errors when running existing applications):
- </para>
-
-
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>causing errors</secondary>
- </indexterm>
-
- <para>
- <emphasis role="bold">Non-compliance in limits or
- behavior</emphasis> (may result in errors when running
- existing applications):
- </para>
-
- <itemizedlist>
-
<listitem>
<indexterm>
<primary>memory use</primary>
@@ -289,369 +303,358 @@
<secondary>and MySQL Cluster</secondary>
</indexterm>
- <para>
- <emphasis role="bold">Memory Usage</emphasis>:
- </para>
-
- <para>
+ <formalpara>
+ <title>Memory usage and recovery</title>
+ <para>
Memory comsumed when data is inserted into an
<literal>NDB</literal> table is not automatically
recovered when deleted, as it is with other storage
engines. Instead, the following rules hold true:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ A <literal>DELETE</literal> statement on an
+ <literal>NDB</literal> table makes the memory formerly
+ used by the deleted rows available for re-use by
+ inserts on the same table only. This memory cannot be
+ used by other <literal>NDB</literal> tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A <literal>DROP TABLE</literal> or
+ <literal>TRUNCATE</literal> operation on an
+ <literal>NDB</literal> table frees the memory that was
+ used by this table for re-use by any
+ <literal>NDB</literal> table, either by the
+ same table or by another <literal>NDB</literal> table.
+ </para>
+ <note>
+ <para>
+ Recall that <literal>TRUNCATE</literal> drops and
+ re-creates the table. See <xref linkend="truncate"/>.
+ </para>
+ </note>
+ <para>
+ Memory freed by <literal>DELETE</literal> operations
+ but still allocated to a specific table can also be
+ made available for general re-use by performing a
+ rolling restart of the cluster. See
+ <xref linkend="mysql-cluster-rolling-restart"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <formalpara>
+ <title>Limits imposed by the cluster's configuration</title>
+
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>imposed by configuration</secondary>
+ </indexterm>
+ <para>
+ A number of hard limits exist which are configurable, but
+ available main memory in the cluster sets limits. See the
+ complete list of configuration parameters in
+ <xref linkend="mysql-cluster-config-file"/>. Most
+ configuration parameters can be upgraded online. These
+ hard limits include:<itemizedlist>
+
+ <listitem>
+ <para>
+ Database memory size and index memory size
+ (<literal>DataMemory</literal> and
+ <literal>IndexMemory</literal>, respectively).
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> is allocated as 32KB
+ pages. As each <literal>DataMemory</literal> page is
+ used, it is assigned to a specific table; once
+ allocated, this memory cannot be freed except by
+ dropping the table.
+ </para>
+
+ <para>
+ See <xref linkend="mysql-cluster-ndbd-definition"/>,
+ for further information about
+ <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The maximum number of operations that can be performed
+ per transaction is set using the configuration
+ parameters
+ <literal>MaxNoOfConcurrentOperations</literal> and
+ <literal>MaxNoOfLocalOperations</literal>. Note that
+ bulk loading, <literal>TRUNCATE TABLE</literal>, and
+ <literal>ALTER TABLE</literal> are handled as special
+ cases by running multiple transactions, and so are not
+ subject to this limitation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Different limits related to tables and indexes. For
+ example, the maximum number of ordered indexes per
+ table is determined by
+ <literal>MaxNoOfOrderedIndexes</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </formalpara>
+
+
+
+
+
+ </listitem>
+ </itemizedlist>
</para>
+ </formalpara>
+
+ </listitem>
+ </itemizedlist>
+
+ </para>
+ </section>
+
+ <section id="mysql-cluster-limitations-transactions">
+
+ <title>Limits Relating to Transaction Handling</title>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>transactions</secondary>
+ </indexterm>
+
+ <para>
+ A numbe of limitations exist in MySQL Cluster with regard to the
+ handling of transactions. These include the following:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>NDBCLUSTER</literal> storage engine supports
+ only the <literal>READ COMMITTED</literal> transaction
+ isolation level.
+ </para>
+ <important>
+ <para>
+ If a
+ <literal>SELECT</literal> from a Cluster table
+ includes a <literal>BLOB</literal> or
+ <literal>TEXT</literal> column, the <literal>READ
+ COMMITTED</literal> transaction isolation level is
+ converted to a read with read lock. This is done to
+ guarantee consistency, due to the fact that parts of
+ the values stored in columns of these types are
+ actually read from a separate table.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>Rollbacks</title>
+ <para>
+ There is no partial rollback of transactions. A duplicate
+ key or similar error rolls back the entire transaction.
+ </para></formalpara>
+ </listitem>
+
+ <listitem>
+ <para>
+ As noted elsewhere in this chapter, MySQL Cluster does not
+ handle large transactions well; it is better to perform a
+ number of small transactions with a few operations each than
+ to attempt a single large transaction containing a great
+ many operations.
+ </para>
+
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>memory usage and transaction handling</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transaction handling</secondary>
+ </indexterm>
+
+ <para>
+ Among other considerations, large transactions require very
+ large amounts of memory. Because of this, the transactional
+ behaviour of a number of MySQL statements is effected as
+ described in the following list:
+
<itemizedlist>
-
+
<listitem>
<para>
- A <literal>DELETE</literal> statement on an
- <literal>NDB</literal> table makes the memory formerly
- used by the deleted rows available for re-use by
- inserts on the same table only. The memory cannot be
- used by other <literal>NDB</literal> tables.
+ <literal>TRUNCATE</literal> is not transactional when
+ used on <literal>NDB</literal> tables. If a
+ <literal>TRUNCATE</literal> fails to empty the table,
+ then it must be re-run until it is successful.
</para>
</listitem>
-
+
<listitem>
<para>
- A <literal>DROP TABLE</literal> or
- <literal>TRUNCATE</literal> operation on an
- <literal>NDB</literal> table frees the memory that was
- used by this table for re-use by any
- <literal>NDB</literal> table — either by the
- same table or by another <literal>NDB</literal> table.
+ <literal>DELETE FROM</literal> (even with no
+ <literal>WHERE</literal> clause)
+ <emphasis>is</emphasis> transactional. For tables
+ containing a great many rows, you may find that
+ performance is improved by using several
+ <literal>DELETE FROM ... LIMIT ...</literal>
+ statements to <quote>chunk</quote> the delete
+ operation. If your objective is to empty the table,
+ then you may wish to use
+ <literal>TRUNCATE</literal> instead.
</para>
-
- <para>
- (Recall that <literal>TRUNCATE</literal> drops and
- re-creates the table. See <xref linkend="truncate"/>.)
- </para>
-
- <para>
- Memory freed by <literal>DELETE</literal> operations
- but still allocated to a specific table can also be
- made available for general re-use by performing a
- rolling restart of the cluster. See
- <xref linkend="mysql-cluster-rolling-restart"/>.
- </para>
</listitem>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- <emphasis role="bold">Error Reporting</emphasis>:
- </para>
-
- <itemizedlist>
-
+
<listitem>
+ <formalpara>
+ <title><literal>LOAD DATA</literal> statements</title>
<para>
- A duplicate key error returns the error message
- <errortext>ERROR 23000: Can't write; duplicate key in
- table
- '<replaceable>tbl_name</replaceable>'</errortext>.
+ <literal>LOAD DATA INFILE</literal> is not
+ transactional when used on <literal>NDB</literal>
+ tables.
+ <important>
+ <para>
+ When executing a <literal>LOAD DATA
+ INFILE</literal> statement, the
+ <literal>NDB</literal> engine can and does commit
+ at will.
+ </para>
+ </important>
+ <literal>LOAD DATA FROM MASTER</literal> is not
+ supported in MySQL Cluster.
</para>
+ </formalpara>
</listitem>
-
+
<listitem>
+ <formalpara>
+ <title><literal>ALTER TABLE</literal> and transactions</title>
<para>
- Like other MySQL storage engines, the
- <literal>NDB</literal> storage engine can handle a
- maximum of one <literal>AUTO_INCREMENT</literal>
- column per table. However, in the case of a Cluster
- table with no explicit primary key, an
- <literal>AUTO_INCREMENT</literal> column is
- automatically defined and used as a
- <quote>hidden</quote> primary key. For this reason,
- you cannot define a table that has an explicit
- <literal>AUTO_INCREMENT</literal> column unless that
- column is also declared using the <literal>PRIMARY
- KEY</literal> option.
+ When copying an <literal>NDB</literal> table as part
+ of an <literal>ALTER TABLE</literal>, the creation of
+ the copy is non-transactional. (In any case, this
+ operation is rolled back when the copy is deleted.)
</para>
-
- <para>
- Attempting to create a table with an
- <literal>AUTO_INCREMENT</literal> column that is not
- the table's primary key, and using the
- <literal>NDB</literal> storage engine, fails with an
- error.
- </para>
+ </formalpara>
</listitem>
-
+
</itemizedlist>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>transactions</secondary>
- </indexterm>
-
- <para>
- <emphasis role="bold">Transaction Handling</emphasis>:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>NDB Cluster</literal> supports only the
- <literal>READ COMMITTED</literal> transaction
- isolation level.
- </para>
+ </para>
+
+
</listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id="mysql-cluster-limitations-error-handling">
+ <title>Error Handling</title>
+
+ <para>
+ Starting, stopping, or restarting a node may give rise to
+ temporary errors causing some transactions to fail. These include
+ the following cases:
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When first starting a node, it is possible that
+ you may see Error 1204 <errortext>Temporary
+ failure, distribution changed</errortext> and
+ similar temporary errors.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The stopping or failure of any data node can
+ result in a number of different node failure
+ errors. (However, there should be no aborted
+ transactions when performing a planned shutdown of
+ the cluster.)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
- <listitem>
- <para>
- There is no partial rollback of transactions. A
- duplicate key or similar error results in a rollback
- of the entire transaction.
- </para>
- </listitem>
+
- <listitem>
<para>
- <emphasis role="bold">Important</emphasis>: If a
- <literal>SELECT</literal> from a Cluster table
- includes a <literal>BLOB</literal> or
- <literal>TEXT</literal> column, the <literal>READ
- COMMITTED</literal> transaction isolation level is
- converted to a read with read lock. This is done to
- guarantee consistency, due to the fact that parts of
- the values stored in columns of these types are
- actually read from a separate table.
- </para>
- </listitem>
-
- <listitem>
- <para>
- As noted elsewhere in this chapter, MySQL Cluster does
- not handle large transactions well; it is better to
- perform a number of small transactions with a few
- operations each than to attempt a single large
- transaction containing a great many operations.
- </para>
-
- <para>
- Among other considerations, large transactions require
- very large amounts of memory. Because of this, the
- transactional behaviour of a number of MySQL
- statements is effected as described in the following
- list:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>TRUNCATE</literal> is not transactional
- when used on <literal>NDB</literal> tables. If a
- <literal>TRUNCATE</literal> fails to empty the
- table, then it must be re-run until it is
- successful.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>DELETE FROM</literal> (even with no
- <literal>WHERE</literal> clause)
- <emphasis>is</emphasis> transactional. For tables
- containing a great many rows, you may find that
- performance is improved by using several
- <literal>DELETE FROM ... LIMIT ...</literal>
- statements to <quote>chunk</quote> the delete
- operation. If the objective is to empty the table,
- then you may wish to use
- <literal>TRUNCATE</literal> instead.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>LOAD DATA INFILE</literal> is not
- transactional when used on <literal>NDB</literal>
- tables. <emphasis>During such an operation, the
- <literal>NDB</literal> engine can and does commit
- at will.</emphasis>
- </para>
-
- <para>
- <literal>LOAD DATA FROM MASTER</literal> is not
- supported in MySQL Cluster.
- </para>
- </listitem>
-
- <listitem>
- <para>
- When copying a table as part of an <literal>ALTER
- TABLE</literal>, the creation of the copy is
- non-transactional. (In any case, this operation is
- rolled back when the copy is deleted.)
- </para>
- </listitem>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- <emphasis role="bold">Node Start, Stop, or
- Restart:</emphasis>: Starting, stopping, or restarting
- a node may give rise to temporary errors causing some
- transactions to fail. These include the following
- cases:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- When first starting a node, it is possible that
- you may see Error 1204 <errortext>Temporary
- failure, distribution changed</errortext> and
- similar temporary errors.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The stopping or failure of any data node can
- result in a number of different node failure
- errors. (However, there should be no aborted
- transactions when performing a planned shutdown of
- the cluster.)
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
In either of these cases, any errors that are
generated must be handled within the application. This
should be done by retrying the transaction.
</para>
- </listitem>
+
- </itemizedlist>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>imposed by configuration</secondary>
- </indexterm>
-
- <para>
- A number of hard limits exist which are configurable, but
- available main memory in the cluster sets limits. See the
- complete list of configuration parameters in
- <xref linkend="mysql-cluster-config-file"/>. Most
- configuration parameters can be upgraded online. These
- hard limits include:
+ <para>
+ See also <xref linkend="mysql-cluster-limitations-limits"/>.
+ </para>
+
+ </section>
+ <section id="mysql-cluster-limitations-database-objects">
+ <title>Limits Associated with Database Objects</title>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>database objects</secondary>
+ </indexterm>
+ <para>
+ Some database objects such as tables and indexes have different
+ limitations when using the <literal>NDBCLUSTER</literal> storage
+ engine:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Database names, table names and attribute names cannot be as
+ long in <literal>NDB</literal> tables as when using other
+ table handlers. Attribute names are truncated to 31
+ characters, and if not unique after truncation give rise to
+ errors. Database names and table names can total a maximum
+ of 122 characters.
+ </para>
+
+ <para>
+ In other words, the maximum length for an
+ <literal>NDB</literal> table name is 122 characters, less
+ the number of characters in the name of the database of
+ which that table is a part.
</para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Database memory size and index memory size
- (<literal>DataMemory</literal> and
- <literal>IndexMemory</literal>, respectively).
- </para>
-
- <para>
- <literal>DataMemory</literal> is allocated as 32KB
- pages. As each <literal>DataMemory</literal> page is
- used, it is assigned to a specific table; once
- allocated, this memory cannot be freed except by
- dropping the table.
- </para>
-
- <para>
- See <xref linkend="mysql-cluster-ndbd-definition"/>,
- for further information about
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The maximum number of operations that can be performed
- per transaction is set using the configuration
- parameters
- <literal>MaxNoOfConcurrentOperations</literal> and
- <literal>MaxNoOfLocalOperations</literal>. Note that
- bulk loading, <literal>TRUNCATE TABLE</literal>, and
- <literal>ALTER TABLE</literal> are handled as special
- cases by running multiple transactions, and so are not
- subject to this limitation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Different limits related to tables and indexes. For
- example, the maximum number of ordered indexes per
- table is determined by
- <literal>MaxNoOfOrderedIndexes</literal>.
- </para>
- </listitem>
-
- </itemizedlist>
</listitem>
<listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>database objects</secondary>
- </indexterm>
-
<para>
- Database names, table names and attribute names cannot be
- as long in <literal>NDB</literal> tables as with other
- table handlers. Attribute names are truncated to 31
- characters, and if not unique after truncation give rise
- to errors. Database names and table names can total a
- maximum of 122 characters. (That is, the maximum length
- for an <literal>NDB Cluster</literal> table name is 122
- characters less the number of characters in the name of
- the database of which that table is a part.)
- </para>
- </listitem>
-
- <listitem>
- <para>
- The maximum number of tables in a Cluster database is
+ The maximum number of <literal>NDB</literal> tables is
limited to 20320.
</para>
</listitem>
<listitem>
<para>
- In MySQL 5.1.10 and earlier versions, the maximum number
- of tables having <literal>AUTO_INCREMENT</literal> columns
- — including those belonging to hidden primary keys
- — is 2048.
+ The maximum number of attributes (that is, columns and
+ indexes) per table is limited to 128.
</para>
-
- <para>
- This limitation was lifted in MySQL 5.1.11.
- </para>
</listitem>
<listitem>
<para>
- The maximum number of attributes per table is limited to
- 128.
- </para>
- </listitem>
-
- <listitem>
- <para>
The maximum permitted size of any one row is 8KB. Note
that each <literal>BLOB</literal> or
<literal>TEXT</literal> column contributes 256 + 8 = 264
@@ -664,56 +667,65 @@
The maximum number of attributes per key is 32.
</para>
</listitem>
+ </itemizedlist>
+
+ </para>
+ </section>
+ <section id="mysql-cluster-limitations-unsupported-features">
+ <title>Features Not Supported</title>
+
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>unsupported features</secondary>
+ </indexterm>
+
+ <para>
+ A number of features supported by other storage engines are not
+ supported for <literal>NDB</literal> tables. Trying to use any
+ of these features in MySQL Cluster does not cause errors in or of
+ itself; however, errors may occur in applications that expects the
+ features to be supported or enforced:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ The foreign key construct is ignored, just as it is in
+ <literal>MyISAM</literal> tables.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Savepoints and rollbacks to savepoints are ignored as in
+ <literal>MyISAM</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>OPTIMIZE</literal> operations are not supported.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>LOAD TABLE ... FROM MASTER</literal> is not
+ supported.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ <itemizedlist>
- </itemizedlist>
- </listitem>
+
<listitem>
<indexterm>
<primary>MySQL Cluster limitations</primary>
- <secondary>unsupported features</secondary>
- </indexterm>
-
- <para>
- <emphasis role="bold">Unsupported features</emphasis> (do not
- cause errors, but are not supported or enforced):
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The foreign key construct is ignored, just as it is in
- <literal>MyISAM</literal> tables.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Savepoints and rollbacks to savepoints are ignored as in
- <literal>MyISAM</literal>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>OPTIMIZE</literal> operations are not supported.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>LOAD TABLE ... FROM MASTER</literal> is not
- supported.
- </para>
- </listitem>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
<secondary>performance</secondary>
</indexterm>
@@ -1306,6 +1318,19 @@
5.1.8. (Bug #17431)
</para>
</listitem>
+
+ <listitem>
+ <para>
+ In MySQL 5.1.10 and earlier versions, the maximum number
+ of tables having <literal>AUTO_INCREMENT</literal> columns
+ — including those belonging to hidden primary keys
+ — was 2048.
+ </para>
+
+ <para>
+ This limitation was lifted in MySQL 5.1.11.
+ </para>
+ </listitem>
</itemizedlist>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6507 - trunk/refman-5.1 | jon | 17 May |
