Author: paul
Date: 2006-03-09 14:19:59 +0100 (Thu, 09 Mar 2006)
New Revision: 1541
Log:
r8505@frost: paul | 2006-03-09 07:12:15 -0600
Add notes from Heikki about InnoDB primary keys.
underfill -> under-fill
Change too-generic section entity.
Modified:
trunk/
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/renamed-nodes.txt
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/renamed-nodes.txt
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/renamed-nodes.txt
trunk/refman-5.1/sql-syntax.xml
trunk/refman-common/titles.en.ent
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8504
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3795
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:8505
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3795
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-4.1/innodb.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -4729,6 +4729,17 @@
<listitem>
<para>
+ In <literal>InnoDB</literal>, having a long <literal>PRIMARY
+ KEY</literal> wastes a lot of disk space because its value
+ must be stored with every secondary index record. (See
+ <xref linkend="innodb-table-and-index"/>.) Create an
+ <literal>AUTO_INCREMENT</literal> column as the primary key if
+ your primary key is long.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
If the Unix <filename>top</filename> tool or the Windows Task
Manager shows that the CPU usage percentage with your workload
is less than 70%, your workload is probably disk-bound. Maybe
@@ -5445,9 +5456,9 @@
</section>
- <section id="table-and-index">
+ <section id="innodb-table-and-index">
- <title>&title-table-and-index;</title>
+ <title>&title-innodb-table-and-index;</title>
<para>
MySQL stores its data dictionary information for tables in
Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-4.1/renamed-nodes.txt 2006-03-09 13:19:59 UTC (rev 1541)
@@ -115,3 +115,4 @@
backing-up innodb-backup
system-variables server-system-variables
windows-system-requirements windows-installation
+table-and-index innodb-table-and-index
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-4.1/sql-syntax.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -1667,6 +1667,12 @@
<literal>NULL</literal> columns as the <literal>PRIMARY
KEY</literal>.
</para>
+
+ <para>
+ In <literal>InnoDB</literal> tables, having a long
+ <literal>PRIMARY KEY</literal> wastes a lot of space. (See
+ <xref linkend="innodb-table-and-index"/>.)
+ </para>
</listitem>
<listitem>
@@ -3345,7 +3351,7 @@
<para>
<literal>DELETE QUICK</literal> is not useful when deleted
- values lead to underfilled index blocks spanning a range of
+ values lead to undef-filled index blocks spanning a range of
index values for which new inserts occur again. In this case,
use of <literal>QUICK</literal> can lead to wasted space in the
index that remains unreclaimed. Here is an example of such a
@@ -3379,14 +3385,14 @@
<para>
In this scenario, the index blocks associated with the deleted
- index values become underfilled but are not merged with other
+ index values become undef-filled but are not merged with other
index blocks due to the use of <literal>QUICK</literal>. They
- remain underfilled when new inserts occur, because new rows does
- not have index values in the deleted range. Furthermore, they
- remain underfilled even if you later use
+ remain undef-filled when new inserts occur, because new rows
+ does not have index values in the deleted range. Furthermore,
+ they remain undef-filled even if you later use
<literal>DELETE</literal> without <literal>QUICK</literal>,
unless some of the deleted index values happen to lie in index
- blocks within or adjacent to the underfilled blocks. To reclaim
+ blocks within or adjacent to the undef-filled blocks. To reclaim
unused index space under these circumstances, use
<literal>OPTIMIZE TABLE</literal>.
</para>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.0/innodb.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -4671,6 +4671,17 @@
<listitem>
<para>
+ In <literal>InnoDB</literal>, having a long <literal>PRIMARY
+ KEY</literal> wastes a lot of disk space because its value
+ must be stored with every secondary index record. (See
+ <xref linkend="innodb-table-and-index"/>.) Create an
+ <literal>AUTO_INCREMENT</literal> column as the primary key if
+ your primary key is long.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
If the Unix <filename>top</filename> tool or the Windows Task
Manager shows that the CPU usage percentage with your workload
is less than 70%, your workload is probably disk-bound. Maybe
@@ -5384,9 +5395,9 @@
</section>
- <section id="table-and-index">
+ <section id="innodb-table-and-index">
- <title>&title-table-and-index;</title>
+ <title>&title-innodb-table-and-index;</title>
<para>
MySQL stores its data dictionary information for tables in
Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.0/renamed-nodes.txt 2006-03-09 13:19:59 UTC (rev 1541)
@@ -414,3 +414,4 @@
backing-up innodb-backup
system-variables server-system-variables
windows-system-requirements windows-installation
+table-and-index innodb-table-and-index
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.0/sql-syntax.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -1695,6 +1695,12 @@
<literal>NULL</literal> columns as the <literal>PRIMARY
KEY</literal>.
</para>
+
+ <para>
+ In <literal>InnoDB</literal> tables, having a long
+ <literal>PRIMARY KEY</literal> wastes a lot of space. (See
+ <xref linkend="innodb-table-and-index"/>.)
+ </para>
</listitem>
<listitem>
@@ -3313,7 +3319,7 @@
<para>
<literal>DELETE QUICK</literal> is not useful when deleted
- values lead to underfilled index blocks spanning a range of
+ values lead to undef-filled index blocks spanning a range of
index values for which new inserts occur again. In this case,
use of <literal>QUICK</literal> can lead to wasted space in the
index that remains unreclaimed. Here is an example of such a
@@ -3347,14 +3353,14 @@
<para>
In this scenario, the index blocks associated with the deleted
- index values become underfilled but are not merged with other
+ index values become undef-filled but are not merged with other
index blocks due to the use of <literal>QUICK</literal>. They
- remain underfilled when new inserts occur, because new rows does
- not have index values in the deleted range. Furthermore, they
- remain underfilled even if you later use
+ remain undef-filled when new inserts occur, because new rows
+ does not have index values in the deleted range. Furthermore,
+ they remain undef-filled even if you later use
<literal>DELETE</literal> without <literal>QUICK</literal>,
unless some of the deleted index values happen to lie in index
- blocks within or adjacent to the underfilled blocks. To reclaim
+ blocks within or adjacent to the undef-filled blocks. To reclaim
unused index space under these circumstances, use
<literal>OPTIMIZE TABLE</literal>.
</para>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.1/innodb.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -4624,6 +4624,17 @@
<listitem>
<para>
+ In <literal>InnoDB</literal>, having a long <literal>PRIMARY
+ KEY</literal> wastes a lot of disk space because its value
+ must be stored with every secondary index record. (See
+ <xref linkend="innodb-table-and-index"/>.) Create an
+ <literal>AUTO_INCREMENT</literal> column as the primary key if
+ your primary key is long.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
If the Unix <filename>top</filename> tool or the Windows Task
Manager shows that the CPU usage percentage with your workload
is less than 70%, your workload is probably disk-bound. Maybe
@@ -5337,9 +5348,9 @@
</section>
- <section id="table-and-index">
+ <section id="innodb-table-and-index">
- <title>&title-table-and-index;</title>
+ <title>&title-innodb-table-and-index;</title>
<para>
MySQL stores its data dictionary information for tables in
Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.1/renamed-nodes.txt 2006-03-09 13:19:59 UTC (rev 1541)
@@ -122,3 +122,4 @@
system-variables server-system-variables
windows-system-requirements windows-installation
mysqld-max mysqld
+table-and-index innodb-table-and-index
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-5.1/sql-syntax.xml 2006-03-09 13:19:59 UTC (rev 1541)
@@ -2152,6 +2152,12 @@
<literal>NULL</literal> columns as the <literal>PRIMARY
KEY</literal>.
</para>
+
+ <para>
+ In <literal>InnoDB</literal> tables, having a long
+ <literal>PRIMARY KEY</literal> wastes a lot of space. (See
+ <xref linkend="innodb-table-and-index"/>.)
+ </para>
</listitem>
<listitem>
@@ -4530,9 +4536,9 @@
In this scenario, the index blocks associated with the deleted
index values become under-filled but are not merged with other
index blocks due to the use of <literal>QUICK</literal>. They
- remain under-filled when new inserts occur, because new rows does
- not have index values in the deleted range. Furthermore, they
- remain under-filled even if you later use
+ remain under-filled when new inserts occur, because new rows
+ do not have index values in the deleted range. Furthermore,
+ they remain under-filled even if you later use
<literal>DELETE</literal> without <literal>QUICK</literal>,
unless some of the deleted index values happen to lie in index
blocks within or adjacent to the under-filled blocks. To reclaim
Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent 2006-03-09 13:19:43 UTC (rev 1540)
+++ trunk/refman-common/titles.en.ent 2006-03-09 13:19:59 UTC (rev 1541)
@@ -1628,7 +1628,7 @@
<!ENTITY title-symbolic-links-to-databases "Using Symbolic Links for Databases on Unix">
<!ENTITY title-symbolic-links-to-tables "Using Symbolic Links for Tables on Unix">
<!ENTITY title-system "System Factors and Startup Parameter Tuning">
-<!ENTITY title-table-and-index "<literal>InnoDB</literal> Table and Index Structures">
+<!ENTITY title-innodb-table-and-index "<literal>InnoDB</literal> Table and Index Structures">
<!ENTITY title-table-cache "How MySQL Opens and Closes Tables">
<!ENTITY title-table-constraints-table "The <literal>INFORMATION_SCHEMA TABLE_CONSTRAINTS</literal> Table">
<!ENTITY title-table-definition-issues "Table Definition-Related Issues">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1541 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 9 Mar |
