List:Commits« Previous MessageNext Message »
From:paul Date:January 17 2006 5:24am
Subject:svn commit - mysqldoc@docsrva: r864 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-17 06:24:19 +0100 (Tue, 17 Jan 2006)
New Revision: 864

Log:
 r6278@frost:  paul | 2006-01-16 23:24:06 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/optimization.xml
   trunk/refman-4.1/problems.xml
   trunk/refman-4.1/renamed-nodes.txt
   trunk/refman-4.1/replication.xml
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/problems.xml
   trunk/refman-5.0/renamed-nodes.txt
   trunk/refman-5.0/replication.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.0/storage-engines.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/problems.xml
   trunk/refman-5.1/renamed-nodes.txt
   trunk/refman-5.1/replication.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-5.1/storage-engines.xml
   trunk/refman-common/titles.en.ent


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6273
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2229
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6278
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2229

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/optimization.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -2577,7 +2577,7 @@
               The criteria for when this happens are too complicated to
               be specified here. So maybe it is worth adding a phrase
               "so if you need to figure out #key parts used, better use
-              logic described then simply rely in key_len value."
+              logic described than simply rely on key_len value."
             </remark>
           </listitem>
 
@@ -4582,10 +4582,9 @@
       <para>
         <literal>InnoDB</literal> uses row locks and
         <literal>BDB</literal> uses page locks. For these two storage
-        engines, deadlocks are possible. This occurs because
-        <literal>InnoDB</literal> automatically acquires row locks and
-        <literal>BDB</literal> acquires page locks during the processing
-        of SQL statements, not at the start of the transaction.
+        engines, deadlocks are possible because they automatically
+        acquire locks during the processing of SQL statements, not at
+        the start of the transaction.
       </para>
 
       <para>
@@ -4609,7 +4608,7 @@
 
         <listitem>
           <para>
-            Makes it possible to lock a single row for a long time.
+            Possible to lock a single row for a long time.
           </para>
         </listitem>
 
@@ -4623,34 +4622,26 @@
 
         <listitem>
           <para>
-            Takes more memory than page-level or table-level locks.
+            Requires more memory than page-level or table-level locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is slower than page-level or table-level locks when used on
-            a large part of the table because you must acquire many more
+            Slower than page-level or table-level locks when used on a
+            large part of the table because you must acquire many more
             locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is definitely much slower than other locks if you often do
+            Definitely much slower than other locks if you often do
             <literal>GROUP BY</literal> operations on a large part of
-            the data or if you often must scan the entire table.
+            the data or if you must scan the entire table frequently.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            With higher-level locks, you can also more easily tune
-            applications by supporting locks of different types, because
-            the lock overhead is less than for row-level locks.
-          </para>
-        </listitem>
-
       </itemizedlist>
 
       <para>
@@ -4668,8 +4659,9 @@
 
         <listitem>
           <para>
-            Reads and updates on strict keys, where you update or delete
-            a row that can be fetched with a single key read:
+            A mix of reads and writes, where writes are updates or
+            deletes for a single row that can be fetched with one key
+            read:
           </para>
 
 <programlisting>
@@ -4697,6 +4689,12 @@
       </itemizedlist>
 
       <para>
+        With higher-level locks, you can more easily tune applications
+        by supporting locks of different types, because the lock
+        overhead is less than for row-level locks.
+      </para>
+
+      <para>
         Options other than row-level or page-level locking:
       </para>
 
@@ -4765,33 +4763,44 @@
 
       <para>
         For large tables, table locking is much better than row locking
-        for most applications, but there are some pitfalls.
+        for most applications, but there are some pitfalls:
       </para>
 
-      <para>
-        Table locking enables many threads to read from a table at the
-        same time, but if a thread wants to write to a table, it must
-        first get exclusive access. During the update, all other threads
-        that want to access this particular table must wait until the
-        update is done.
-      </para>
+      <itemizedlist>
 
-      <para>
-        Table updates normally are considered to be more important than
-        table retrievals, so they are given higher priority. This should
-        ensure that updates to a table are not <quote>starved</quote>
-        even if there is heavy <literal>SELECT</literal> activity for
-        the table.
-      </para>
+        <listitem>
+          <para>
+            Table locking enables many threads to read from a table at
+            the same time, but if a thread wants to write to a table, it
+            must first get exclusive access. During the update, all
+            other threads that want to access this particular table must
+            wait until the update is done.
+          </para>
+        </listitem>
 
-      <para>
-        Table locking causes problems in cases such as when a thread is
-        waiting because the disk is full and free space needs to become
-        available before the thread can proceed. In this case, all
-        threads that want to access the problem table are also put in a
-        waiting state until more disk space is made available.
-      </para>
+        <listitem>
+          <para>
+            Table updates normally are considered to be more important
+            than table retrievals, so they are given higher priority.
+            This should ensure that updates to a table are not
+            <quote>starved</quote> even if there is heavy
+            <literal>SELECT</literal> activity for the table.
+          </para>
+        </listitem>
 
+        <listitem>
+          <para>
+            Table locking causes problems in cases such as when a thread
+            is waiting because the disk is full and free space needs to
+            become available before the thread can proceed. In this
+            case, all threads that want to access the problem table are
+            also put in a waiting state until more disk space is made
+            available.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
         Table locking is also disadvantageous under the following
         scenario:
@@ -4829,7 +4838,7 @@
       </itemizedlist>
 
       <para>
-        The following list describes some ways to avoid or reduce
+        The following items describe some ways to avoid or reduce
         contention caused by table locking:
       </para>
 
@@ -4838,8 +4847,8 @@
         <listitem>
           <para>
             Try to get the <literal>SELECT</literal> statements to run
-            faster. You might have to create some summary tables to do
-            this.
+            faster so that they lock tables for a shorter time. You
+            might have to create some summary tables to do this.
           </para>
         </listitem>
 
@@ -4959,9 +4968,9 @@
         <listitem>
           <para>
             You can use <literal>LOCK TABLES</literal> to increase
-            speed, as many updates within a single lock is much faster
-            than updating without locks. Splitting table contents into
-            separate tables may also help.
+            speed, because many updates within a single lock is much
+            faster than updating without locks. Splitting table contents
+            into separate tables may also help.
           </para>
         </listitem>
 
@@ -5103,11 +5112,11 @@
 
       <para>
         One of the most basic optimizations is to design your tables to
-        take as little space on the disk as possible. This can give huge
-        improvements because disk reads are faster, and smaller tables
-        normally require less main memory while their contents are being
-        actively processed during query execution. Indexing also is a
-        lesser resource burden if done on smaller columns.
+        take as little space on the disk as possible. This can result in
+        huge improvements because disk reads are faster, and smaller
+        tables normally require less main memory while their contents
+        are being actively processed during query execution. Indexing
+        also is a lesser resource burden if done on smaller columns.
       </para>
 
       <para>
@@ -5119,8 +5128,8 @@
       </para>
 
       <para>
-        You can get better performance on a table and minimize storage
-        space using the techniques listed here:
+        You can get better performance for a table and minimize storage
+        space by using the techniques listed here:
       </para>
 
       <itemizedlist>
@@ -5129,13 +5138,8 @@
           <para>
             Use the most efficient (smallest) data types possible. MySQL
             has many specialized types that save disk space and memory.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Use the smaller integer types if possible to get smaller
-            tables. For example, <literal>MEDIUMINT</literal> is often a
+            For example, use the smaller integer types if possible to
+            get smaller tables. <literal>MEDIUMINT</literal> is often a
             better choice than <literal>INT</literal> because a
             <literal>MEDIUMINT</literal> column uses 25% less space.
           </para>
@@ -5160,9 +5164,8 @@
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
-            <literal>VARCHAR</literal> columns with the
-            <literal>CREATE</literal> option
-            <literal>ROW_FORMAT=fixed</literal>.
+            <literal>VARCHAR</literal> columns with the <literal>CREATE
+            TABLE</literal> option <literal>ROW_FORMAT=FIXED</literal>.
           </para>
         </listitem>
 
@@ -5178,7 +5181,7 @@
             Create only the indexes that you really need. Indexes are
             good for retrieval but bad when you need to store data
             quickly. If you access a table mostly by searching on a
-            combination of columns, make an index on them. The first
+            combination of columns, create an index on them. The first
             part of the index should be the column most used. If you
             <emphasis>always</emphasis> use many columns when selecting
             from the table, you should use the column with more
@@ -5188,15 +5191,14 @@
 
         <listitem>
           <para>
-            If it is very likely that a column has a unique prefix on
-            the first number of characters, it's better to index only
-            this prefix, using MySQL's support for creating an index on
-            the leftmost part of a character column (see
-            <xref linkend="create-index"/>). Shorter indexes are faster
-            &mdash; not only because they require less disk space
-            &mdash; but because they give also you more hits in the
-            index cache, and thus fewer disk seeks. See
-            <xref linkend="server-parameters"/>.
+            If it is very likely that a string column has a unique
+            prefix on the first number of characters, it's better to
+            index only this prefix, using MySQL's support for creating
+            an index on the leftmost part of the column (see
+            <xref linkend="create-index"/>). Shorter indexes are faster,
+            not only because they require less disk space, but because
+            they give also you more hits in the index cache, and thus
+            fewer disk seeks. See <xref linkend="server-parameters"/>.
           </para>
         </listitem>
 
@@ -5204,7 +5206,7 @@
           <para>
             In some circumstances, it can be beneficial to split into
             two a table that is scanned very often. This is especially
-            true if it is a dynamic format table and it is possible to
+            true if it is a dynamic-format table and it is possible to
             use a smaller static format table that can be used to find
             the relevant rows when scanning the table.
           </para>
@@ -5246,16 +5248,6 @@
         least 256 bytes. Most storage engines have higher limits.
       </para>
 
-      <para>
-        With
-        <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
-        syntax in an index specification, you can create an index that
-        uses only the first <replaceable>length</replaceable> characters
-        of a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column. Indexing only a prefix of column values in this way can
-        make the index file much smaller.
-      </para>
-
       <indexterm>
         <primary><literal>BLOB</literal> columns</primary>
         <secondary>indexing</secondary>
@@ -5307,21 +5299,21 @@
         supports <literal>FULLTEXT</literal> indexes and only for
         <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
         <literal>TEXT</literal> columns. Indexing always takes place
-        over the entire column and partial (prefix) indexing is not
-        supported. See <xref linkend="fulltext-search"/>, for details.
+        over the entire column and partial (column prefix) indexing is
+        not supported. For details, see
+        <xref linkend="fulltext-search"/>.
       </para>
 
       <para>
         As of MySQL 4.1.0, you can create indexes on spatial data types.
-        Currently, spatial types are supported only by the
-        <literal>MyISAM</literal> storage engine. Spatial indexes use
-        R-trees.
+        Spatial indexes use R-trees. Currently, only
+        <literal>MyISAM</literal> supports indexes on spatial types.
       </para>
 
       <para>
         The <literal>MEMORY</literal> (<literal>HEAP</literal>) storage
-        engine uses hash indexes by default. It also supports B-tree
-        indexes as of MySQL 4.1.0.
+        engine uses <literal>HASH</literal> indexes by default. It also
+        supports <literal>BTREE</literal> indexes as of MySQL 4.1.0.
       </para>
 
     </section>
@@ -5345,9 +5337,10 @@
       </indexterm>
 
       <para>
-        MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain data types, you can
-        index a prefix of the column (see <xref linkend="indexes"/>).
+        MySQL can create composite indexes (that is, indexes on multiple
+        columns). An index may consist of up to 15 columns. For certain
+        data types, you can index a prefix of the column (see
+        <xref linkend="indexes"/>).
       </para>
 
       <para>
@@ -5378,11 +5371,11 @@
 </programlisting>
 
       <para>
-        The <literal>name</literal> index is an index over
+        The <literal>name</literal> index is an index over the
+        <literal>last_name</literal> and <literal>first_name</literal>
+        columns. The index can be used for queries that specify values
+        in a known range for <literal>last_name</literal>, or for both
         <literal>last_name</literal> and <literal>first_name</literal>.
-        The index can be used for queries that specify values in a known
-        range for <literal>last_name</literal>, or for both
-        <literal>last_name</literal> and <literal>first_name</literal>.
         Therefore, the <literal>name</literal> index is used in the
         following queries:
       </para>
@@ -5440,9 +5433,8 @@
         determine the position to seek to in the middle of the data file
         without having to look at all the data. If a table has 1,000
         rows, this is at least 100 times faster than reading
-        sequentially. Note that if you need to access most of the rows,
-        it is faster to read sequentially, because this minimizes disk
-        seeks.
+        sequentially. If you need to access most of the rows, it is
+        faster to read sequentially, because this minimizes disk seeks.
       </para>
 
       <para>
@@ -5467,7 +5459,7 @@
       </para>
 
       <para>
-        Indexes are used for these operations:
+        MySQL uses indexes for these operations:
       </para>
 
       <itemizedlist>
@@ -5499,12 +5491,12 @@
             <literal>MAX()</literal> value for a specific indexed column
             <replaceable>key_col</replaceable>. This is optimized by a
             preprocessor that checks whether you are using
-            <literal>WHERE <replaceable>key_part_#</replaceable> =
+            <literal>WHERE <replaceable>key_part_N</replaceable> =
             <replaceable>constant</replaceable></literal> on all key
             parts that occur before <replaceable>key_col</replaceable>
             in the index. In this case, MySQL does a single key lookup
             for each <literal>MIN()</literal> or
-            <literal>MAX()</literal> expression and replace it with a
+            <literal>MAX()</literal> expression and replaces it with a
             constant. If all expressions are replaced with constants,
             the query returns at once. For example:
           </para>
@@ -5550,7 +5542,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;</userinput>
+mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;</userinput>
 </programlisting>
 
       <para>
@@ -5588,11 +5580,11 @@
       </para>
 
 <programlisting>
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;
 
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2 AND col3=val3;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable> AND col3=<replaceable>val3</replaceable>;
 </programlisting>
 
       <para>
@@ -5874,7 +5866,7 @@
       </para>
 
       <para>
-        You can control the size of the key cache by means of the
+        To control the size of the key cache, use the
         <literal>key_buffer_size</literal> system variable. If this
         variable is set equal to zero, no key cache is used. The key
         cache also is not used if the <literal>key_buffer_size</literal>
@@ -6000,8 +5992,9 @@
           not eliminate contention among threads entirely. They still
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
-          MySQL 4.1.1 also provides multiple key caches, which enables
-          you to assign different table indexes to different key caches.
+          MySQL 4.1.1 also provides multiple key caches. This feature
+          enables you to assign different table indexes to different key
+          caches.
         </para>
 
         <para>
@@ -6011,12 +6004,9 @@
           <literal>MyISAM</literal> table indexes are cached in the
           default key cache. To assign table indexes to a specific key
           cache, use the <literal>CACHE INDEX</literal> statement (see
-          <xref linkend="cache-index"/>).
-        </para>
-
-        <para>
-          For example, the following statement assigns indexes from the
-          tables <literal>t1</literal>, <literal>t2</literal>, and
+          <xref linkend="cache-index"/>). For example, the following
+          statement assigns indexes from the tables
+          <literal>t1</literal>, <literal>t2</literal>, and
           <literal>t3</literal> to the key cache named
           <literal>hot_cache</literal>:
         </para>
@@ -6065,7 +6055,7 @@
         </para>
 
 <programlisting>
-mysql&gt; <userinput>set global key_buffer_size = 0;</userinput>
+mysql&gt; <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
 
 mysql&gt; <userinput>show variables like 'key_buffer_size';</userinput>
 +-----------------+---------+
@@ -6199,8 +6189,8 @@
         </para>
 
 <programlisting>
-CACHE INDEX a.t1, a.t2, b.t3 IN hot_cache
-CACHE INDEX a.t4, b.t5, b.t6 IN cold_cache
+CACHE INDEX db1.t1, db1.t2, db2.t3 IN hot_cache
+CACHE INDEX db1.t4, db2.t5, db2.t6 IN cold_cache
 </programlisting>
 
       </section>
@@ -6213,7 +6203,7 @@
           By default, the key cache management system of MySQL 4.1 uses
           the LRU strategy for choosing key cache blocks to be evicted,
           but it also supports a more sophisticated method called the
-          "midpoint insertion strategy."
+          <firstterm>midpoint insertion strategy.</firstterm>
         </para>
 
         <para>
@@ -6263,7 +6253,7 @@
           The threshold value prescribes that, for a key cache
           containing <replaceable>N</replaceable> blocks, the block at
           the beginning of the hot sub-chain not accessed within the
-          last <literal><replaceable>N</replaceable> *
+          last <literal><replaceable>N</replaceable> &times;
           key_cache_age_threshold / 100</literal> hits is to be moved to
           the beginning of the warm sub-chain. It then becomes the first
           candidate for eviction, because blocks for replacement always
@@ -6620,7 +6610,8 @@
 
         <listitem>
           <para>
-            Execute <command>myisamchk --stats_method=method_name
+            Execute <command>myisamchk
+            --stats_method=<replaceable>method_name</replaceable>
             --analyze</command>
           </para>
         </listitem>
@@ -6671,12 +6662,40 @@
 
     </section>
 
-    <section id="open-tables">
+    <section id="table-cache">
 
-      <title>&title-open-tables;</title>
+      <title>&title-table-cache;</title>
 
+      <indexterm type="function">
+        <primary>table_cache</primary>
+      </indexterm>
+
       <indexterm>
         <primary>tables</primary>
+        <secondary>opening</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
+        <secondary>closing</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>opening</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>closing</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>table cache</primary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
         <secondary>open</secondary>
       </indexterm>
 
@@ -6712,45 +6731,6 @@
       </para>
 
       <para>
-        You can read more about this topic in the next section. See
-        <xref linkend="table-cache"/>.
-      </para>
-
-    </section>
-
-    <section id="table-cache">
-
-      <title>&title-table-cache;</title>
-
-      <indexterm type="function">
-        <primary>table_cache</primary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>opening</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>closing</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>opening</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>closing</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>table cache</primary>
-      </indexterm>
-
-      <para>
         The <literal>table_cache</literal>,
         <literal>max_connections</literal>, and
         <literal>max_tmp_tables</literal> system variables affect the
@@ -6768,10 +6748,10 @@
         <literal>table_cache</literal> is related to
         <literal>max_connections</literal>. For example, for 200
         concurrent running connections, you should have a table cache
-        size of at least <literal>200 *
+        size of at least <literal>200 &times;
         <replaceable>N</replaceable></literal>, where
         <replaceable>N</replaceable> is the maximum number of tables per
-        join in any of the queries which you execute. You also need to
+        join in any of the queries which you execute. You must also
         reserve some extra file descriptors for temporary tables and
         files.
       </para>
@@ -6801,8 +6781,8 @@
       </para>
 
       <para>
-        An unused table is closed and removed from the table cache under
-        the following circumstances:
+        MySQL closes an unused table and removes it from the table cache
+        under the following circumstances:
       </para>
 
       <itemizedlist>
@@ -6877,10 +6857,10 @@
         table or if a thread accesses the table twice in the same query
         (for example, by joining the table to itself). Each concurrent
         open requires an entry in the table cache. The first open of any
-        table takes two file descriptors: one for the data file and one
-        for the index file. Each additional use of the table takes only
-        one file descriptor for the data file. The index file descriptor
-        is shared among all threads.
+        <literal>MyISAM</literal> table takes two file descriptors: one
+        for the data file and one for the index file. Each additional
+        use of the table takes only one file descriptor for the data
+        file. The index file descriptor is shared among all threads.
       </para>
 
       <para>
@@ -6974,7 +6954,7 @@
         decisions must be made very early to achieve large performance
         gains. In other cases, a quick look at this section may suffice.
         However, it is always nice to have a sense of how much can be
-        gained by changing things at this level.
+        gained by changing factors that apply at this level.
       </para>
 
       <para>
@@ -7024,31 +7004,30 @@
           </para>
 
           <para>
-            Note that the <option>--skip-external-locking</option>
-            option does not affect MySQL's functionality as long as you
-            run only one server. Just remember to take down the server
-            (or lock and flush the relevant tables) before you run
-            <command>myisamchk</command>. On some systems this option is
-            mandatory, because the external locking does not work in any
-            case.
+            Note that disabling external locking does not affect MySQL's
+            functionality as long as you run only one server. Just
+            remember to take down the server (or lock and flush the
+            relevant tables) before you run
+            <command>myisamchk</command>. On some systems it is
+            mandatory to disable external locking because it does not
+            work, anyway.
           </para>
 
           <para>
-            The only case in which you cannot use
-            <option>--skip-external-locking</option> is if you run
-            multiple MySQL <emphasis>servers</emphasis> (not clients) on
-            the same data, or if you run <command>myisamchk</command> to
-            check (not repair) a table without telling the server to
-            flush and lock the tables first. Note that using multiple
-            MySQL servers to access the same data concurrently is
-            generally <emphasis>not</emphasis> recommended, except when
-            using MySQL Cluster.
+            The only case in which you cannot disable external locking
+            is when you run multiple MySQL <emphasis>servers</emphasis>
+            (not clients) on the same data, or if you run
+            <command>myisamchk</command> to check (not repair) a table
+            without telling the server to flush and lock the tables
+            first. Note that using multiple MySQL servers to access the
+            same data concurrently is generally <emphasis>not</emphasis>
+            recommended, except when using MySQL Cluster.
           </para>
 
           <para>
-            You can still use <literal>LOCK TABLES</literal> and
-            <literal>UNLOCK TABLES</literal> even if you are using
-            <option>--skip-external-locking</option>.
+            The <literal>LOCK TABLES</literal> and <literal>UNLOCK
+            TABLES</literal> statements use internal locking, so you can
+            use them even if external locking is disabled.
           </para>
         </listitem>
 
@@ -7146,8 +7125,8 @@
 
       <para>
         If there is a <command>mysqld</command> server currently
-        running, you can see what values it actually is using for the
-        system variables by connecting to it and issuing this statement:
+        running, you can see the current values of its system variables
+        by connecting to it and issuing this statement:
       </para>
 
 <programlisting>
@@ -7174,8 +7153,8 @@
 </programlisting>
 
       <para>
-        You can find a full description for all system and status
-        variables in <xref linkend="server-system-variables"/>, and
+        For a full description for all system and status variables, see
+        <xref linkend="server-system-variables"/>, and
         <xref linkend="server-status-variables"/>.
       </para>
 
@@ -7310,11 +7289,12 @@
         <filename>my-large.cnf</filename>,
         <filename>my-medium.cnf</filename>, and
         <filename>my-small.cnf</filename>. You can use these as a basis
-        for optimizing your system.
+        for optimizing your system. (On Windows, look in the MySQL
+        installation directory.)
       </para>
 
       <para>
-        Note that if you specify an option on the command line for
+        If you specify an option on the command line for
         <command>mysqld</command> or <command>mysqld_safe</command>, it
         remains in effect only for that invocation of the server. To use
         the option every time the server runs, put it in an option file.
@@ -7590,8 +7570,8 @@
 
             <listitem>
               <para>
-                A stack (default 64KB, variable
-                <literal>thread_stack</literal>)
+                A stack (default 64KB before MySQL 4.0.10 and 192KB
+                thereafter, variable <literal>thread_stack</literal>)
               </para>
             </listitem>
 
@@ -7662,10 +7642,10 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>MEMORY</literal>) tables.
-            Temporary tables with a large row length (calculated as the
-            sum of all column lengths) or that contain
-            <literal>BLOB</literal> columns are stored on disk.
+            tables are memory-based hash tables. Temporary tables with a
+            large row length (calculated as the sum of all column
+            lengths) or that contain <literal>BLOB</literal> columns are
+            stored on disk.
           </para>
 
           <para>
@@ -7709,7 +7689,7 @@
             Almost all parsing and calculating is done in a local memory
             store. No memory overhead is needed for small items, so the
             normal slow memory allocation and freeing is avoided. Memory
-            is allocated only for unexpectedly large strings; this is
+            is allocated only for unexpectedly large strings. This is
             done with <literal>malloc()</literal> and
             <literal>free()</literal>.
           </para>
@@ -7722,7 +7702,7 @@
             is opened once and the data file is opened once for each
             concurrently running thread. For each concurrent thread, a
             table structure, column structures for each column, and a
-            buffer of size <literal>3 *
+            buffer of size <literal>3 &times;
             <replaceable>N</replaceable></literal> are allocated (where
             <replaceable>N</replaceable> is the maximum row length, not
             counting <literal>BLOB</literal> columns). A
@@ -7850,7 +7830,7 @@
       </para>
 
       <para>
-        If you want to disallow TCP/IP connections entirely, start
+        To disallow TCP/IP connections entirely, start
         <command>mysqld</command> with the
         <option>--skip-networking</option> option.
       </para>
@@ -7923,14 +7903,15 @@
             <para>
               Striping means that you have many disks and put the first
               block on the first disk, the second block on the second
-              disk, and the <replaceable>N</replaceable>th block on the
-              (<literal><replaceable>N</replaceable> mod
-              number_of_disks</literal>) disk, and so on. This means if
-              your normal data size is less than the stripe size (or
-              perfectly aligned), you get much better performance.
-              Striping is very dependent on the operating system and the
-              stripe size, so benchmark your application with different
-              stripe sizes. See <xref linkend="custom-benchmarks"/>.
+              disk, and the <replaceable>N</replaceable>-th block on the
+              (<literal><replaceable>N</replaceable> MOD
+              <replaceable>number_of_disks</replaceable></literal>)
+              disk, and so on. This means if your normal data size is
+              less than the stripe size (or perfectly aligned), you get
+              much better performance. Striping is very dependent on the
+              operating system and the stripe size, so benchmark your
+              application with different stripe sizes. See
+              <xref linkend="custom-benchmarks"/>.
             </para>
 
             <para>
@@ -7948,11 +7929,13 @@
 
       <listitem>
         <para>
-          For reliability you may want to use RAID 0+1 (striping plus
-          mirroring), but in this case, you need 2*N drives to hold N
-          drives of data. This is probably the best option if you have
-          the money for it. However, you may also have to invest in some
-          volume-management software to handle it efficiently.
+          For reliability, you may want to use RAID 0+1 (striping plus
+          mirroring), but in this case, you need 2 &times;
+          <replaceable>N</replaceable> drives to hold
+          <replaceable>N</replaceable> drives of data. This is probably
+          the best option if you have the money for it. However, you may
+          also have to invest in some volume-management software to
+          handle it efficiently.
         </para>
       </listitem>
 
@@ -7962,9 +7945,9 @@
           critical a type of data is. For example, store semi-important
           data that can be regenerated on a RAID 0 disk, but store
           really important data such as host information and logs on a
-          RAID 0+1 or RAID N disk. RAID N can be a problem if you have
-          many writes, due to the time required to update the parity
-          bits.
+          RAID 0+1 or RAID <replaceable>N</replaceable> disk. RAID
+          <replaceable>N</replaceable> can be a problem if you have many
+          writes, due to the time required to update the parity bits.
         </para>
       </listitem>
 
@@ -8079,12 +8062,12 @@
 </programlisting>
 
         <para>
-          For any table <literal>tbl_a</literal> in
+          The result is that, or any table <literal>tbl_a</literal> in
           <literal>db1</literal>, there also appears to be a table
           <literal>tbl_a</literal> in <literal>db2</literal>. If one
           client updates <literal>db1.tbl_a</literal> and another client
           updates <literal>db2.tbl_a</literal>, problems are likely to
-          result.
+          occur.
         </para>
 
         <para>
@@ -8116,16 +8099,6 @@
 if (1)
 </programlisting>
 
-        <para>
-          On Windows, you can use internal symbolic links to directories
-          by compiling MySQL with <option>-DUSE_SYMDIR</option>. This
-          allows you to put different databases on different disks. See
-          <xref linkend="windows-symbolic-links"/>. (It is necessary to
-          define <literal>USE_SYMDIR</literal> explicitly only before
-          MySQL 4.0. As of MySQL 4.0, symbolic link support is enabled
-          by default for all Windows servers.)
-        </para>
-
       </section>
 
       <section id="symbolic-links-to-tables">
@@ -8160,10 +8133,9 @@
 
         <para>
           In MySQL 4.0, symlinks are fully supported only for
-          <literal>MyISAM</literal> tables. For other storage engines,
-          you may get strange problems if you try to use symbolic links
-          on files in the operating system with any of the preceding
-          statements.
+          <literal>MyISAM</literal> tables. For files used by tables for
+          other storage engines, you may get strange problems if you try
+          to use symbolic links.
         </para>
 
         <para>
@@ -8175,11 +8147,12 @@
 
           <listitem>
             <para>
-              In the data directory, you always have the table
-              definition file, the data file, and the index file. The
-              data file and index file can be moved elsewhere and
-              replaced in the data directory by symlinks. The definition
-              file cannot.
+              In the data directory, you always have the table format
+              (<filename>.frm</filename>) file, the data
+              (<filename>.MYD</filename>) file, and the index
+              (<filename>.MYI</filename>) file. The data file and index
+              file can be moved elsewhere and replaced in the data
+              directory by symlinks. The format file cannot.
             </para>
           </listitem>
 
@@ -8192,14 +8165,14 @@
 
           <listitem>
             <para>
-              Symlinking can be accomplished manually from the command
-              line using <command>ln -s</command> if
-              <command>mysqld</command> is not running. Alternatively,
-              you can instruct a running MySQL server to perform the
+              You can instruct a running MySQL server to perform the
               symlinking by using the <literal>DATA DIRECTORY</literal>
               and <literal>INDEX DIRECTORY</literal> options to
               <literal>CREATE TABLE</literal>. See
-              <xref linkend="create-table"/>.
+              <xref linkend="create-table"/>. Alternatively, symlinking
+              can be accomplished manually from the command line using
+              <literal>ln -s</literal> if <command>mysqld</command> is
+              not running.
             </para>
           </listitem>
 
@@ -8374,39 +8347,27 @@
           <command>mysqld-max</command> and
           <literal>mysql-max-nt</literal> servers for Windows are
           compiled with the <option>-DUSE_SYMDIR</option> option. This
-          allows you to put a database directory on a different disk by
+          enables you to put a database directory on a different disk by
           setting up a symbolic link to it. This is similar to the way
           that symbolic links work on Unix, although the procedure for
           setting up the link is different.
         </para>
 
         <para>
-          As of MySQL 4.0, symbolic links are enabled by default. If you
-          do not need them, you can disable them with the
-          <option>skip-symbolic-links</option> option:
+          It is necessary to define <literal>USE_SYMDIR</literal>
+          explicitly only before MySQL 4.0; for
+          <command>mysqld-max</command> and
+          <literal>mysql-max-nt</literal>, you can enable symbolic links
+          by using the <option>--symbolic-links</option> option. As of
+          MySQL 4.0, symbolic links are enabled by default for all
+          Windows servers. If you do not need them, you can disable them
+          with the <option>--skip-symbolic-links</option> option.
         </para>
 
-<programlisting>
-[mysqld]
-skip-symbolic-links
-</programlisting>
-
         <para>
-          Before MySQL 4.0, symbolic links are disabled by default. To
-          enable them, you should put the following entry in your
-          <filename>my.cnf</filename> or <filename>my.ini</filename>
-          file:
-        </para>
-
-<programlisting>
-[mysqld]
-symbolic-links
-</programlisting>
-
-        <para>
-          On Windows, you can create a symbolic link to a MySQL database
-          by creating a file in the data directory that contains the
-          path to the destination directory. The file should be named
+          On Windows, you create a symbolic link to a MySQL database by
+          creating a file in the data directory that contains the path
+          to the destination directory. The file should be named
           <filename><replaceable>db_name</replaceable>.sym</filename>,
           where <replaceable>db_name</replaceable> is the database name.
         </para>
@@ -8415,8 +8376,8 @@
           Suppose that the MySQL data directory is
           <filename>C:\mysql\data</filename> and you want to have
           database <literal>foo</literal> located at
-          <filename>D:\data\foo</filename>. Set up a symlink as shown
-          here:
+          <filename>D:\data\foo</filename>. Set up a symlink using this
+          procedure:
         </para>
 
         <orderedlist>
@@ -8424,12 +8385,13 @@
           <listitem>
             <para>
               Make sure that the <filename>D:\data\foo</filename>
-              directory exists by creating it if necessary. If you have
-              a database directory named <filename>foo</filename> in the
-              data directory, you should move it to
-              <filename>D:\data</filename>. Otherwise, the symbolic link
-              is ineffective. To avoid problems, the server should not
-              be running when you move the database directory.
+              directory exists by creating it if necessary. If you
+              already have a database directory named
+              <filename>foo</filename> in the data directory, you should
+              move it to <filename>D:\data</filename>. Otherwise, the
+              symbolic link will be ineffective. To avoid problems, make
+              sure that the server is not running when you move the
+              database directory.
             </para>
           </listitem>
 

Modified: trunk/refman-4.1/problems.xml
===================================================================
--- trunk/refman-4.1/problems.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/problems.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -5097,7 +5097,7 @@
 
         <listitem>
           <para>
-            Due to the way table definition files are stored, you cannot
+            Due to the way table format (<filename>.frm</filename>) files are stored, you cannot
             use character 255 (<literal>CHAR(255)</literal>) in table
             names, column names, or enumerations. This is scheduled to
             be fixed in version 5.1 when we implement new table

Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/renamed-nodes.txt	2006-01-17 05:24:19 UTC (rev 864)
@@ -99,3 +99,4 @@
 charset-cast charset-convert
 charset-defaults charset-syntax
 charset-config-file adding-character-set
+open-tables table-cache

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/replication.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -1186,8 +1186,8 @@
           way to take a binary snapshot of <literal>InnoDB</literal>
           tables is to shut down the master server and copy the
           <literal>InnoDB</literal> data files, log files, and table
-          definition files (<filename>.frm</filename> files). To record
-          the current log file name and offset, you should issue the
+          format files (<filename>.frm</filename> files). To record the
+          current log file name and offset, you should issue the
           following statements before you shut down the server:
         </para>
 

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -173,7 +173,9 @@
         includes <replaceable>table_options</replaceable> modifications,
         for options such as <literal>ENGINE</literal>,
         <literal>AUTO_INCREMENT</literal>, and
-        <literal>AVG_ROW_LENGTH</literal>. See
+        <literal>AVG_ROW_LENGTH</literal>. (However, <literal>ALTER
+        TABLE</literal> ignores the <literal>DATA DIRECTORY</literal>
+        and <literal>INDEX DIRECTORY</literal> table options.) See
         <xref linkend="create-table"/>.
       </para>
 
@@ -623,14 +625,6 @@
 
         <listitem>
           <para>
-            <literal>ALTER TABLE</literal> ignores the <literal>DATA
-            DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
-            table options.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             <indexterm type="function">
               <primary>CONVERT TO</primary>
             </indexterm>
@@ -8782,7 +8776,7 @@
 
         <listitem>
           <para>
-            As long as the table definition file
+            As long as the table format file
             <filename><replaceable>tbl_name</replaceable>.frm</filename>
             is valid, the table can be re-created as an empty table with
             <literal>TRUNCATE TABLE</literal>, even if the data or index

Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-4.1/storage-engines.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -460,10 +460,10 @@
       Each <literal>MyISAM</literal> table is stored on disk in three
       files. The files have names that begin with the table name and
       have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition. The
-      data file has an <filename>.MYD</filename>
-      (<literal>MYData</literal>) extension. The index file has an
-      <filename>.MYI</filename> (<literal>MYIndex</literal>) extension.
+      <filename>.frm</filename> file stores the table format. The data
+      file has an <filename>.MYD</filename> (<literal>MYData</literal>)
+      extension. The index file has an <filename>.MYI</filename>
+      (<literal>MYIndex</literal>) extension.
     </para>
 
     <para>
@@ -1659,7 +1659,7 @@
       When you create a <literal>MERGE</literal> table, MySQL creates
       two files on disk. The files have names that begin with the table
       name and have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition, and an
+      <filename>.frm</filename> file stores the table format, and an
       <filename>.MRG</filename> file contains the names of the tables
       that should be used as one. (Originally, all used tables had to be
       in the same database as the <literal>MERGE</literal> table itself.
@@ -2852,8 +2852,8 @@
         Each <literal>BDB</literal> table is stored on disk in two
         files. The files have names that begin with the table name and
         have an extension to indicate the file type. An
-        <filename>.frm</filename> file stores the table definition, and
-        a <filename>.db</filename> file contains the table data and
+        <filename>.frm</filename> file stores the table format, and a
+        <filename>.db</filename> file contains the table data and
         indexes.
       </para>
 
@@ -3327,11 +3327,10 @@
 
     <para>
       When you create an <literal>EXAMPLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table. Retrievals return an empty
-      result.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. No other files are created. No data can be stored into
+      the table. Retrievals return an empty result.
     </para>
 
 <programlisting>
@@ -3404,14 +3403,14 @@
 
     <para>
       When you create an <literal>ARCHIVE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. The storage engine creates
-      other files, all having names beginning with the table name. The
-      data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>,
-      respectively. An <filename>.ARN</filename> file may appear during
-      optimization operations.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. The storage engine creates other files, all having
+      names beginning with the table name. The data and metadata files
+      have extensions of <filename>.ARZ</filename> and
+      <filename>.ARM</filename>, respectively. An
+      <filename>.ARN</filename> file may appear during optimization
+      operations.
     </para>
 
     <para>
@@ -3542,7 +3541,7 @@
 
     <para>
       When you create a <literal>CSV</literal> table, the server creates
-      a table definition file in the database directory. The file begins
+      a table format file in the database directory. The file begins
       with the table name and has an <filename>.frm</filename>
       extension. The storage engine also creates a data file. Its name
       begins with the table name and has a <filename>.CSV</filename>
@@ -3638,10 +3637,9 @@
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. There are no other files
-      associated with the table.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. There are no other files associated with the table.
     </para>
 
     <para>

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/optimization.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -2745,7 +2745,7 @@
               The criteria for when this happens are too complicated to
               be specified here. So maybe it is worth adding a phrase
               "so if you need to figure out #key parts used, better use
-              logic described then simply rely in key_len value."
+              logic described than simply rely on key_len value."
             </remark>
           </listitem>
 
@@ -6031,10 +6031,9 @@
       <para>
         <literal>InnoDB</literal> uses row locks and
         <literal>BDB</literal> uses page locks. For these two storage
-        engines, deadlocks are possible. This occurs because
-        <literal>InnoDB</literal> automatically acquires row locks and
-        <literal>BDB</literal> acquires page locks during the processing
-        of SQL statements, not at the start of the transaction.
+        engines, deadlocks are possible because they automatically
+        acquire locks during the processing of SQL statements, not at
+        the start of the transaction.
       </para>
 
       <para>
@@ -6058,7 +6057,7 @@
 
         <listitem>
           <para>
-            Makes it possible to lock a single row for a long time.
+            Possible to lock a single row for a long time.
           </para>
         </listitem>
 
@@ -6072,34 +6071,26 @@
 
         <listitem>
           <para>
-            Takes more memory than page-level or table-level locks.
+            Requires more memory than page-level or table-level locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is slower than page-level or table-level locks when used on
-            a large part of the table because you must acquire many more
+            Slower than page-level or table-level locks when used on a
+            large part of the table because you must acquire many more
             locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is definitely much slower than other locks if you often do
+            Definitely much slower than other locks if you often do
             <literal>GROUP BY</literal> operations on a large part of
-            the data or if you often must scan the entire table.
+            the data or if you must scan the entire table frequently.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            With higher-level locks, you can also more easily tune
-            applications by supporting locks of different types, because
-            the lock overhead is less than for row-level locks.
-          </para>
-        </listitem>
-
       </itemizedlist>
 
       <para>
@@ -6117,8 +6108,9 @@
 
         <listitem>
           <para>
-            Reads and updates on strict keys, where you update or delete
-            a row that can be fetched with a single key read:
+            A mix of reads and writes, where writes are updates or
+            deletes for a single row that can be fetched with one key
+            read:
           </para>
 
 <programlisting>
@@ -6146,6 +6138,12 @@
       </itemizedlist>
 
       <para>
+        With higher-level locks, you can more easily tune applications
+        by supporting locks of different types, because the lock
+        overhead is less than for row-level locks.
+      </para>
+
+      <para>
         Options other than row-level or page-level locking:
       </para>
 
@@ -6214,33 +6212,44 @@
 
       <para>
         For large tables, table locking is much better than row locking
-        for most applications, but there are some pitfalls.
+        for most applications, but there are some pitfalls:
       </para>
 
-      <para>
-        Table locking enables many threads to read from a table at the
-        same time, but if a thread wants to write to a table, it must
-        first get exclusive access. During the update, all other threads
-        that want to access this particular table must wait until the
-        update is done.
-      </para>
+      <itemizedlist>
 
-      <para>
-        Table updates normally are considered to be more important than
-        table retrievals, so they are given higher priority. This should
-        ensure that updates to a table are not <quote>starved</quote>
-        even if there is heavy <literal>SELECT</literal> activity for
-        the table.
-      </para>
+        <listitem>
+          <para>
+            Table locking enables many threads to read from a table at
+            the same time, but if a thread wants to write to a table, it
+            must first get exclusive access. During the update, all
+            other threads that want to access this particular table must
+            wait until the update is done.
+          </para>
+        </listitem>
 
-      <para>
-        Table locking causes problems in cases such as when a thread is
-        waiting because the disk is full and free space needs to become
-        available before the thread can proceed. In this case, all
-        threads that want to access the problem table are also put in a
-        waiting state until more disk space is made available.
-      </para>
+        <listitem>
+          <para>
+            Table updates normally are considered to be more important
+            than table retrievals, so they are given higher priority.
+            This should ensure that updates to a table are not
+            <quote>starved</quote> even if there is heavy
+            <literal>SELECT</literal> activity for the table.
+          </para>
+        </listitem>
 
+        <listitem>
+          <para>
+            Table locking causes problems in cases such as when a thread
+            is waiting because the disk is full and free space needs to
+            become available before the thread can proceed. In this
+            case, all threads that want to access the problem table are
+            also put in a waiting state until more disk space is made
+            available.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
         Table locking is also disadvantageous under the following
         scenario:
@@ -6278,7 +6287,7 @@
       </itemizedlist>
 
       <para>
-        The following list describes some ways to avoid or reduce
+        The following items describe some ways to avoid or reduce
         contention caused by table locking:
       </para>
 
@@ -6287,8 +6296,8 @@
         <listitem>
           <para>
             Try to get the <literal>SELECT</literal> statements to run
-            faster. You might have to create some summary tables to do
-            this.
+            faster so that they lock tables for a shorter time. You
+            might have to create some summary tables to do this.
           </para>
         </listitem>
 
@@ -6407,9 +6416,9 @@
         <listitem>
           <para>
             You can use <literal>LOCK TABLES</literal> to increase
-            speed, as many updates within a single lock is much faster
-            than updating without locks. Splitting table contents into
-            separate tables may also help.
+            speed, because many updates within a single lock is much
+            faster than updating without locks. Splitting table contents
+            into separate tables may also help.
           </para>
         </listitem>
 
@@ -6551,11 +6560,11 @@
 
       <para>
         One of the most basic optimizations is to design your tables to
-        take as little space on the disk as possible. This can give huge
-        improvements because disk reads are faster, and smaller tables
-        normally require less main memory while their contents are being
-        actively processed during query execution. Indexing also is a
-        lesser resource burden if done on smaller columns.
+        take as little space on the disk as possible. This can result in
+        huge improvements because disk reads are faster, and smaller
+        tables normally require less main memory while their contents
+        are being actively processed during query execution. Indexing
+        also is a lesser resource burden if done on smaller columns.
       </para>
 
       <para>
@@ -6567,8 +6576,8 @@
       </para>
 
       <para>
-        You can get better performance on a table and minimize storage
-        space using the techniques listed here:
+        You can get better performance for a table and minimize storage
+        space by using the techniques listed here:
       </para>
 
       <itemizedlist>
@@ -6577,13 +6586,8 @@
           <para>
             Use the most efficient (smallest) data types possible. MySQL
             has many specialized types that save disk space and memory.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Use the smaller integer types if possible to get smaller
-            tables. For example, <literal>MEDIUMINT</literal> is often a
+            For example, use the smaller integer types if possible to
+            get smaller tables. <literal>MEDIUMINT</literal> is often a
             better choice than <literal>INT</literal> because a
             <literal>MEDIUMINT</literal> column uses 25% less space.
           </para>
@@ -6608,9 +6612,8 @@
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
-            <literal>VARCHAR</literal> columns with the
-            <literal>CREATE</literal> option
-            <literal>ROW_FORMAT=fixed</literal>.
+            <literal>VARCHAR</literal> columns with the <literal>CREATE
+            TABLE</literal> option <literal>ROW_FORMAT=FIXED</literal>.
           </para>
         </listitem>
 
@@ -6629,21 +6632,21 @@
 
           <para>
             The compact <literal>InnoDB</literal> format also changes
-            the way how <literal>CHAR</literal> columns containing UTF-8
-            data are stored. In the
-            <literal>ROW_FORMAT=REDUNDANT</literal> format, a UTF-8
-            <literal>CHAR(<replaceable>n</replaceable>)</literal>
-            occupies 3*<replaceable>n</replaceable> bytes, given that
-            the maximum length of a UTF-8 encoded character is 3 bytes.
-            Many languages can be written mostly with single-byte UTF-8
-            characters, so a fixed storage length often wastes space.
-            The <literal>ROW_FORMAT=COMPACT</literal> format allocates a
-            variable amount of
-            <replaceable>n</replaceable>..3*<replaceable>n</replaceable>
-            bytes for these columns by stripping trailing spaces if
-            necessary. The minimum storage length is kept as
-            <replaceable>n</replaceable> bytes in order to facilitate
-            in-place updates in typical cases.
+            how <literal>CHAR</literal> columns containing UTF-8 data
+            are stored. With <literal>ROW_FORMAT=REDUNDANT</literal>, a
+            UTF-8 <literal>CHAR(<replaceable>N</replaceable>)</literal>
+            occupies 3 &times; <replaceable>N</replaceable> bytes, given
+            that the maximum length of a UTF-8 encoded character is
+            three bytes. Many languages can be written primarily using
+            single-byte UTF-8 characters, so a fixed storage length
+            often wastes space. With
+            <literal>ROW_FORMAT=COMPACT</literal> format,
+            <literal>InnoDB</literal> allocates a variable amount of
+            storage in the range from <replaceable>N</replaceable> to 3
+            &times; <replaceable>N</replaceable> bytes for these columns
+            by stripping trailing spaces if necessary. The minimum
+            storage length is kept as <replaceable>N</replaceable> bytes
+            in order to facilitate in-place updates in typical cases.
           </para>
         </listitem>
 
@@ -6659,7 +6662,7 @@
             Create only the indexes that you really need. Indexes are
             good for retrieval but bad when you need to store data
             quickly. If you access a table mostly by searching on a
-            combination of columns, make an index on them. The first
+            combination of columns, create an index on them. The first
             part of the index should be the column most used. If you
             <emphasis>always</emphasis> use many columns when selecting
             from the table, you should use the column with more
@@ -6669,15 +6672,14 @@
 
         <listitem>
           <para>
-            If it is very likely that a column has a unique prefix on
-            the first number of characters, it's better to index only
-            this prefix, using MySQL's support for creating an index on
-            the leftmost part of a character column (see
-            <xref linkend="create-index"/>). Shorter indexes are faster
-            &mdash; not only because they require less disk space
-            &mdash; but because they give also you more hits in the
-            index cache, and thus fewer disk seeks. See
-            <xref linkend="server-parameters"/>.
+            If it is very likely that a string column has a unique
+            prefix on the first number of characters, it's better to
+            index only this prefix, using MySQL's support for creating
+            an index on the leftmost part of the column (see
+            <xref linkend="create-index"/>). Shorter indexes are faster,
+            not only because they require less disk space, but because
+            they give also you more hits in the index cache, and thus
+            fewer disk seeks. See <xref linkend="server-parameters"/>.
           </para>
         </listitem>
 
@@ -6685,7 +6687,7 @@
           <para>
             In some circumstances, it can be beneficial to split into
             two a table that is scanned very often. This is especially
-            true if it is a dynamic format table and it is possible to
+            true if it is a dynamic-format table and it is possible to
             use a smaller static format table that can be used to find
             the relevant rows when scanning the table.
           </para>
@@ -6727,16 +6729,6 @@
         least 256 bytes. Most storage engines have higher limits.
       </para>
 
-      <para>
-        With
-        <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
-        syntax in an index specification, you can create an index that
-        uses only the first <replaceable>length</replaceable> characters
-        of a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column. Indexing only a prefix of column values in this way can
-        make the index file much smaller.
-      </para>
-
       <indexterm>
         <primary><literal>BLOB</literal> columns</primary>
         <secondary>indexing</secondary>
@@ -6758,9 +6750,12 @@
       </indexterm>
 
       <para>
-        The <literal>MyISAM</literal> and <literal>InnoDB</literal>
-        storage engines also support indexing on <literal>BLOB</literal>
-        and <literal>TEXT</literal> columns. When indexing a
+        With
+        <literal><replaceable>col_name</replaceable>(<replaceable>N</replaceable>)</literal>
+        syntax in an index specification, you can create an index that
+        uses only the first <replaceable>N</replaceable> characters of a
+        string column. Indexing only a prefix of column values in this
+        way can make the index file much smaller. When you index a
         <literal>BLOB</literal> or <literal>TEXT</literal> column, you
         <emphasis>must</emphasis> specify a prefix length for the index.
         For example:
@@ -6787,19 +6782,21 @@
         <literal>FULLTEXT</literal> indexes and only for
         <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
         <literal>TEXT</literal> columns. Indexing always takes place
-        over the entire column and partial (prefix) indexing is not
-        supported. See <xref linkend="fulltext-search"/>, for details.
+        over the entire column and partial (column prefix) indexing is
+        not supported. For details, see
+        <xref linkend="fulltext-search"/>.
       </para>
 
       <para>
-        You can also create indexes on spatial data types. Spatial types
-        are supported only by the <literal>MyISAM</literal> storage
-        engine. Spatial indexes use R-trees.
+        You can also create indexes on spatial data types. Spatial
+        indexes use R-trees. Currently, only <literal>MyISAM</literal>
+        supports indexes on spatial types.
       </para>
 
       <para>
-        The <literal>MEMORY</literal> storage engine uses hash indexes
-        by default, but also supports B-tree indexes.
+        The <literal>MEMORY</literal> storage engine uses
+        <literal>HASH</literal> indexes by default, but also supports
+        <literal>BTREE</literal> indexes.
       </para>
 
     </section>
@@ -6823,9 +6820,10 @@
       </indexterm>
 
       <para>
-        MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain data types, you can
-        index a prefix of the column (see <xref linkend="indexes"/>).
+        MySQL can create composite indexes (that is, indexes on multiple
+        columns). An index may consist of up to 15 columns. For certain
+        data types, you can index a prefix of the column (see
+        <xref linkend="indexes"/>).
       </para>
 
       <para>
@@ -6856,11 +6854,11 @@
 </programlisting>
 
       <para>
-        The <literal>name</literal> index is an index over
+        The <literal>name</literal> index is an index over the
+        <literal>last_name</literal> and <literal>first_name</literal>
+        columns. The index can be used for queries that specify values
+        in a known range for <literal>last_name</literal>, or for both
         <literal>last_name</literal> and <literal>first_name</literal>.
-        The index can be used for queries that specify values in a known
-        range for <literal>last_name</literal>, or for both
-        <literal>last_name</literal> and <literal>first_name</literal>.
         Therefore, the <literal>name</literal> index is used in the
         following queries:
       </para>
@@ -6918,9 +6916,8 @@
         determine the position to seek to in the middle of the data file
         without having to look at all the data. If a table has 1,000
         rows, this is at least 100 times faster than reading
-        sequentially. Note that if you need to access most of the rows,
-        it is faster to read sequentially, because this minimizes disk
-        seeks.
+        sequentially. If you need to access most of the rows, it is
+        faster to read sequentially, because this minimizes disk seeks.
       </para>
 
       <para>
@@ -6944,7 +6941,7 @@
       </para>
 
       <para>
-        Indexes are used for these operations:
+        MySQL uses indexes for these operations:
       </para>
 
       <itemizedlist>
@@ -6976,12 +6973,12 @@
             <literal>MAX()</literal> value for a specific indexed column
             <replaceable>key_col</replaceable>. This is optimized by a
             preprocessor that checks whether you are using
-            <literal>WHERE <replaceable>key_part_#</replaceable> =
+            <literal>WHERE <replaceable>key_part_N</replaceable> =
             <replaceable>constant</replaceable></literal> on all key
             parts that occur before <replaceable>key_col</replaceable>
             in the index. In this case, MySQL does a single key lookup
             for each <literal>MIN()</literal> or
-            <literal>MAX()</literal> expression and replace it with a
+            <literal>MAX()</literal> expression and replaces it with a
             constant. If all expressions are replaced with constants,
             the query returns at once. For example:
           </para>
@@ -7027,7 +7024,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;</userinput>
+mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;</userinput>
 </programlisting>
 
       <para>
@@ -7065,11 +7062,11 @@
       </para>
 
 <programlisting>
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;
 
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2 AND col3=val3;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable> AND col3=<replaceable>val3</replaceable>;
 </programlisting>
 
       <para>
@@ -7315,9 +7312,9 @@
 
       <para>
         This section first describes the basic operation of the
-        <literal>MyISAM</literal> key cache. Then it discusses recent
-        changes (made in MySQL 4.1) that improve key cache performance
-        and that enable you to better control cache operation:
+        <literal>MyISAM</literal> key cache. Then it discusses features
+        that improve key cache performance and that enable you to better
+        control cache operation:
       </para>
 
       <itemizedlist>
@@ -7339,7 +7336,7 @@
       </itemizedlist>
 
       <para>
-        You can control the size of the key cache by means of the
+        To control the size of the key cache, use the
         <literal>key_buffer_size</literal> system variable. If this
         variable is set equal to zero, no key cache is used. The key
         cache also is not used if the <literal>key_buffer_size</literal>
@@ -7455,9 +7452,8 @@
           not eliminate contention among threads entirely. They still
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
-          MySQL &current-series; also provides multiple key caches,
-          which enables you to assign different table indexes to
-          different key caches.
+          MySQL also provides multiple key caches. This feature enables
+          you to assign different table indexes to different key caches.
         </para>
 
         <para>
@@ -7467,12 +7463,9 @@
           <literal>MyISAM</literal> table indexes are cached in the
           default key cache. To assign table indexes to a specific key
           cache, use the <literal>CACHE INDEX</literal> statement (see
-          <xref linkend="cache-index"/>).
-        </para>
-
-        <para>
-          For example, the following statement assigns indexes from the
-          tables <literal>t1</literal>, <literal>t2</literal>, and
+          <xref linkend="cache-index"/>). For example, the following
+          statement assigns indexes from the tables
+          <literal>t1</literal>, <literal>t2</literal>, and
           <literal>t3</literal> to the key cache named
           <literal>hot_cache</literal>:
         </para>
@@ -7513,7 +7506,7 @@
         </para>
 
 <programlisting>
-mysql&gt; <userinput>set global key_buffer_size = 0;</userinput>
+mysql&gt; <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
 
 mysql&gt; <userinput>show variables like 'key_buffer_size';</userinput>
 +-----------------+---------+
@@ -7647,8 +7640,8 @@
         </para>
 
 <programlisting>
-CACHE INDEX a.t1, a.t2, b.t3 IN hot_cache
-CACHE INDEX a.t4, b.t5, b.t6 IN cold_cache
+CACHE INDEX db1.t1, db1.t2, db2.t3 IN hot_cache
+CACHE INDEX db1.t4, db2.t5, db2.t6 IN cold_cache
 </programlisting>
 
       </section>
@@ -7661,7 +7654,7 @@
           By default, the key cache management system uses the LRU
           strategy for choosing key cache blocks to be evicted, but it
           also supports a more sophisticated method called the
-          <quote>midpoint insertion strategy.</quote>
+          <firstterm>midpoint insertion strategy.</firstterm>
         </para>
 
         <para>
@@ -7711,7 +7704,7 @@
           The threshold value prescribes that, for a key cache
           containing <replaceable>N</replaceable> blocks, the block at
           the beginning of the hot sub-chain not accessed within the
-          last <literal><replaceable>N</replaceable> *
+          last <literal><replaceable>N</replaceable> &times;
           key_cache_age_threshold / 100</literal> hits is to be moved to
           the beginning of the warm sub-chain. It then becomes the first
           candidate for eviction, because blocks for replacement always
@@ -8067,7 +8060,8 @@
 
         <listitem>
           <para>
-            Execute <command>myisamchk --stats_method=method_name
+            Execute <command>myisamchk
+            --stats_method=<replaceable>method_name</replaceable>
             --analyze</command>
           </para>
         </listitem>
@@ -8118,12 +8112,40 @@
 
     </section>
 
-    <section id="open-tables">
+    <section id="table-cache">
 
-      <title>&title-open-tables;</title>
+      <title>&title-table-cache;</title>
 
+      <indexterm type="function">
+        <primary>table_cache</primary>
+      </indexterm>
+
       <indexterm>
         <primary>tables</primary>
+        <secondary>opening</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
+        <secondary>closing</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>opening</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>closing</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>table cache</primary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
         <secondary>open</secondary>
       </indexterm>
 
@@ -8159,45 +8181,6 @@
       </para>
 
       <para>
-        You can read more about this topic in the next section. See
-        <xref linkend="table-cache"/>.
-      </para>
-
-    </section>
-
-    <section id="table-cache">
-
-      <title>&title-table-cache;</title>
-
-      <indexterm type="function">
-        <primary>table_cache</primary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>opening</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>closing</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>opening</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>closing</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>table cache</primary>
-      </indexterm>
-
-      <para>
         The <literal>table_cache</literal>,
         <literal>max_connections</literal>, and
         <literal>max_tmp_tables</literal> system variables affect the
@@ -8215,10 +8198,10 @@
         <literal>table_cache</literal> is related to
         <literal>max_connections</literal>. For example, for 200
         concurrent running connections, you should have a table cache
-        size of at least <literal>200 *
+        size of at least <literal>200 &times;
         <replaceable>N</replaceable></literal>, where
         <replaceable>N</replaceable> is the maximum number of tables per
-        join in any of the queries which you execute. You also need to
+        join in any of the queries which you execute. You must also
         reserve some extra file descriptors for temporary tables and
         files.
       </para>
@@ -8248,8 +8231,8 @@
       </para>
 
       <para>
-        An unused table is closed and removed from the table cache under
-        the following circumstances:
+        MySQL closes an unused table and removes it from the table cache
+        under the following circumstances:
       </para>
 
       <itemizedlist>
@@ -8324,10 +8307,10 @@
         table or if a thread accesses the table twice in the same query
         (for example, by joining the table to itself). Each concurrent
         open requires an entry in the table cache. The first open of any
-        table takes two file descriptors: one for the data file and one
-        for the index file. Each additional use of the table takes only
-        one file descriptor for the data file. The index file descriptor
-        is shared among all threads.
+        <literal>MyISAM</literal> table takes two file descriptors: one
+        for the data file and one for the index file. Each additional
+        use of the table takes only one file descriptor for the data
+        file. The index file descriptor is shared among all threads.
       </para>
 
       <para>
@@ -8421,7 +8404,7 @@
         decisions must be made very early to achieve large performance
         gains. In other cases, a quick look at this section may suffice.
         However, it is always nice to have a sense of how much can be
-        gained by changing things at this level.
+        gained by changing factors that apply at this level.
       </para>
 
       <para>
@@ -8461,37 +8444,38 @@
 
         <listitem>
           <para>
-            Use the <option>--skip-external-locking</option> MySQL
-            option to avoid external locking. This option is on by
-            default.
+            Avoid external locking. Since MySQL 4.0, the default has
+            been for external locking to be disabled on all systems. The
+            <option>--external-locking</option> and
+            <option>--skip-external-locking</option> options explicitly
+            enable and disable external locking.
           </para>
 
           <para>
-            Note that the <option>--skip-external-locking</option>
-            option does not affect MySQL's functionality as long as you
-            run only one server. Just remember to take down the server
-            (or lock and flush the relevant tables) before you run
-            <command>myisamchk</command>. On some systems this option is
-            mandatory, because the external locking does not work in any
-            case.
+            Note that disabling external locking does not affect MySQL's
+            functionality as long as you run only one server. Just
+            remember to take down the server (or lock and flush the
+            relevant tables) before you run
+            <command>myisamchk</command>. On some systems it is
+            mandatory to disable external locking because it does not
+            work, anyway.
           </para>
 
           <para>
-            The only case in which you cannot use
-            <option>--skip-external-locking</option> is if you run
-            multiple MySQL <emphasis>servers</emphasis> (not clients) on
-            the same data, or if you run <command>myisamchk</command> to
-            check (not repair) a table without telling the server to
-            flush and lock the tables first. Note that using multiple
-            MySQL servers to access the same data concurrently is
-            generally <emphasis>not</emphasis> recommended, except when
-            using MySQL Cluster.
+            The only case in which you cannot disable external locking
+            is when you run multiple MySQL <emphasis>servers</emphasis>
+            (not clients) on the same data, or if you run
+            <command>myisamchk</command> to check (not repair) a table
+            without telling the server to flush and lock the tables
+            first. Note that using multiple MySQL servers to access the
+            same data concurrently is generally <emphasis>not</emphasis>
+            recommended, except when using MySQL Cluster.
           </para>
 
           <para>
-            You can still use <literal>LOCK TABLES</literal> and
-            <literal>UNLOCK TABLES</literal> even if you are using
-            <option>--skip-external-locking</option>.
+            The <literal>LOCK TABLES</literal> and <literal>UNLOCK
+            TABLES</literal> statements use internal locking, so you can
+            use them even if external locking is disabled.
           </para>
         </listitem>
 
@@ -8662,8 +8646,8 @@
 
       <para>
         If there is a <command>mysqld</command> server currently
-        running, you can see what values it actually is using for the
-        system variables by connecting to it and issuing this statement:
+        running, you can see the current values of its system variables
+        by connecting to it and issuing this statement:
       </para>
 
 <programlisting>
@@ -8690,8 +8674,8 @@
 </programlisting>
 
       <para>
-        You can find a full description for all system and status
-        variables in <xref linkend="server-system-variables"/>, and
+        For a full description for all system and status variables, see
+        <xref linkend="server-system-variables"/>, and
         <xref linkend="server-status-variables"/>.
       </para>
 
@@ -8796,11 +8780,12 @@
         <filename>my-large.cnf</filename>,
         <filename>my-medium.cnf</filename>, and
         <filename>my-small.cnf</filename>. You can use these as a basis
-        for optimizing your system.
+        for optimizing your system. (On Windows, look in the MySQL
+        installation directory.)
       </para>
 
       <para>
-        Note that if you specify an option on the command line for
+        If you specify an option on the command line for
         <command>mysqld</command> or <command>mysqld_safe</command>, it
         remains in effect only for that invocation of the server. To use
         the option every time the server runs, put it in an option file.
@@ -8880,13 +8865,13 @@
             shows that this kind of <quote>educated guess</quote> rarely
             misses optimal plans, and may dramatically reduce query
             compilation times. That is why this option is on
-            (<literal>optimizer_prune_level</literal>=1) by default.
+            (<literal>optimizer_prune_level=1</literal>) by default.
             However, if you believe that the optimizer missed a better
             query plan, this option can be switched off
-            (<literal>optimizer_prune_level</literal>=0) with the risk
-            that query compilation may take much longer. Notice that
-            even with the use of this heuristic, the optimizer still
-            explores a roughly exponential number of plans.
+            (<literal>optimizer_prune_level=0</literal>) with the risk
+            that query compilation may take much longer. Note that, even
+            with the use of this heuristic, the optimizer still explores
+            a roughly exponential number of plans.
           </para>
         </listitem>
 
@@ -9161,7 +9146,7 @@
 
             <listitem>
               <para>
-                A stack (default 64KB, variable
+                A stack (default 192KB, variable
                 <literal>thread_stack</literal>)
               </para>
             </listitem>
@@ -9232,10 +9217,10 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>MEMORY</literal>) tables.
-            Temporary tables with a large row length (calculated as the
-            sum of all column lengths) or that contain
-            <literal>BLOB</literal> columns are stored on disk.
+            tables are memory-based hash tables. Temporary tables with a
+            large row length (calculated as the sum of all column
+            lengths) or that contain <literal>BLOB</literal> columns are
+            stored on disk.
           </para>
 
           <para>
@@ -9264,7 +9249,7 @@
             Almost all parsing and calculating is done in a local memory
             store. No memory overhead is needed for small items, so the
             normal slow memory allocation and freeing is avoided. Memory
-            is allocated only for unexpectedly large strings; this is
+            is allocated only for unexpectedly large strings. This is
             done with <literal>malloc()</literal> and
             <literal>free()</literal>.
           </para>
@@ -9276,7 +9261,7 @@
             index file is opened once; the data file is opened once for
             each concurrently running thread. For each concurrent
             thread, a table structure, column structures for each
-            column, and a buffer of size <literal>3 *
+            column, and a buffer of size <literal>3 &times;
             <replaceable>N</replaceable></literal> are allocated (where
             <replaceable>N</replaceable> is the maximum row length, not
             counting <literal>BLOB</literal> columns). A
@@ -9403,7 +9388,7 @@
       </para>
 
       <para>
-        If you want to disallow TCP/IP connections entirely, start
+        To disallow TCP/IP connections entirely, start
         <command>mysqld</command> with the
         <option>--skip-networking</option> option.
       </para>
@@ -9476,14 +9461,15 @@
             <para>
               Striping means that you have many disks and put the first
               block on the first disk, the second block on the second
-              disk, and the <replaceable>N</replaceable>th block on the
-              (<literal><replaceable>N</replaceable> mod
-              number_of_disks</literal>) disk, and so on. This means if
-              your normal data size is less than the stripe size (or
-              perfectly aligned), you get much better performance.
-              Striping is very dependent on the operating system and the
-              stripe size, so benchmark your application with different
-              stripe sizes. See <xref linkend="custom-benchmarks"/>.
+              disk, and the <replaceable>N</replaceable>-th block on the
+              (<literal><replaceable>N</replaceable> MOD
+              <replaceable>number_of_disks</replaceable></literal>)
+              disk, and so on. This means if your normal data size is
+              less than the stripe size (or perfectly aligned), you get
+              much better performance. Striping is very dependent on the
+              operating system and the stripe size, so benchmark your
+              application with different stripe sizes. See
+              <xref linkend="custom-benchmarks"/>.
             </para>
 
             <para>
@@ -9501,11 +9487,13 @@
 
       <listitem>
         <para>
-          For reliability you may want to use RAID 0+1 (striping plus
-          mirroring), but in this case, you need 2*N drives to hold N
-          drives of data. This is probably the best option if you have
-          the money for it. However, you may also have to invest in some
-          volume-management software to handle it efficiently.
+          For reliability, you may want to use RAID 0+1 (striping plus
+          mirroring), but in this case, you need 2 &times;
+          <replaceable>N</replaceable> drives to hold
+          <replaceable>N</replaceable> drives of data. This is probably
+          the best option if you have the money for it. However, you may
+          also have to invest in some volume-management software to
+          handle it efficiently.
         </para>
       </listitem>
 
@@ -9515,9 +9503,9 @@
           critical a type of data is. For example, store semi-important
           data that can be regenerated on a RAID 0 disk, but store
           really important data such as host information and logs on a
-          RAID 0+1 or RAID N disk. RAID N can be a problem if you have
-          many writes, due to the time required to update the parity
-          bits.
+          RAID 0+1 or RAID <replaceable>N</replaceable> disk. RAID
+          <replaceable>N</replaceable> can be a problem if you have many
+          writes, due to the time required to update the parity bits.
         </para>
       </listitem>
 
@@ -9632,12 +9620,12 @@
 </programlisting>
 
         <para>
-          For any table <literal>tbl_a</literal> in
+          The result is that, or any table <literal>tbl_a</literal> in
           <literal>db1</literal>, there also appears to be a table
           <literal>tbl_a</literal> in <literal>db2</literal>. If one
           client updates <literal>db1.tbl_a</literal> and another client
           updates <literal>db2.tbl_a</literal>, problems are likely to
-          result.
+          occur.
         </para>
 
         <para>
@@ -9660,11 +9648,6 @@
 if (1)
 </programlisting>
 
-        <para>
-          Note that symbolic link support is enabled by default for all
-          Windows servers.
-        </para>
-
       </section>
 
       <section id="symbolic-links-to-tables">
@@ -9685,16 +9668,11 @@
           statement.
         </para>
 
-        <remark role="todo">
-          Following paras still true for 5.0? [js] (Yes: PD)
-        </remark>
-
         <para>
           Symlinks are fully supported only for
-          <literal>MyISAM</literal> tables. For other storage engines,
-          you may get strange problems if you try to use symbolic links
-          on files in the operating system with any of the preceding
-          statements.
+          <literal>MyISAM</literal> tables. For files used by tables for
+          other storage engines, you may get strange problems if you try
+          to use symbolic links.
         </para>
 
         <para>
@@ -9706,11 +9684,12 @@
 
           <listitem>
             <para>
-              In the data directory, you always have the table
-              definition file, the data file, and the index file. The
-              data file and index file can be moved elsewhere and
-              replaced in the data directory by symlinks. The definition
-              file cannot.
+              In the data directory, you always have the table format
+              (<filename>.frm</filename>) file, the data
+              (<filename>.MYD</filename>) file, and the index
+              (<filename>.MYI</filename>) file. The data file and index
+              file can be moved elsewhere and replaced in the data
+              directory by symlinks. The format file cannot.
             </para>
           </listitem>
 
@@ -9723,14 +9702,14 @@
 
           <listitem>
             <para>
-              Symlinking can be accomplished manually from the command
-              line using <literal>ln -s</literal> if
-              <command>mysqld</command> is not running. Alternatively,
-              you can instruct a running MySQL server to perform the
+              You can instruct a running MySQL server to perform the
               symlinking by using the <literal>DATA DIRECTORY</literal>
               and <literal>INDEX DIRECTORY</literal> options to
               <literal>CREATE TABLE</literal>. See
-              <xref linkend="create-table"/>.
+              <xref linkend="create-table"/>. Alternatively, symlinking
+              can be accomplished manually from the command line using
+              <literal>ln -s</literal> if <command>mysqld</command> is
+              not running.
             </para>
           </listitem>
 
@@ -9896,40 +9875,29 @@
         </indexterm>
 
         <para>
-          The <command>mysqld-max</command> and
-          <literal>mysql-max-nt</literal> servers for Windows are
-          compiled with the <option>-DUSE_SYMDIR</option> option. This
-          allows you to put a database directory on a different disk by
-          setting up a symbolic link to it. This is similar to the way
-          that symbolic links work on Unix, although the procedure for
-          setting up the link is different.
+          Symbolic links are enabled by default for all Windows servers.
+          This enables you to put a database directory on a different
+          disk by setting up a symbolic link to it. This is similar to
+          the way that database symbolic links work on Unix, although
+          the procedure for setting up the link is different. If you do
+          not need symbolic links, you can disable them using the
+          <option>--skip-symbolic-links</option> option.
         </para>
 
         <para>
-          Symbolic links are enabled by default. If you do not need
-          them, you can disable them using the
-          <option>skip-symbolic-links</option> option:
+          On Windows, you create a symbolic link to a MySQL database by
+          creating a file in the data directory that contains the path
+          to the destination directory. The file should be named
+          <filename><replaceable>db_name</replaceable>.sym</filename>,
+          where <replaceable>db_name</replaceable> is the database name.
         </para>
 
-<programlisting>
-[mysqld]
-skip-symbolic-links
-</programlisting>
-
         <para>
-          On Windows, you can create a symbolic link to a MySQL database
-          by creating a file in the data directory that contains the
-          path to the destination directory. The file should be named
-          <filename>db_name.sym</filename>, where
-          <replaceable>db_name</replaceable> is the database name.
-        </para>
-
-        <para>
           Suppose that the MySQL data directory is
           <filename>C:\mysql\data</filename> and you want to have
           database <literal>foo</literal> located at
-          <filename>D:\data\foo</filename>. Set up a symlink as shown
-          here:
+          <filename>D:\data\foo</filename>. Set up a symlink using this
+          procedure
         </para>
 
         <orderedlist>
@@ -9937,12 +9905,13 @@
           <listitem>
             <para>
               Make sure that the <filename>D:\data\foo</filename>
-              directory exists by creating it if necessary. If you have
-              a database directory named <filename>foo</filename> in the
-              data directory, you should move it to
-              <filename>D:\data</filename>. Otherwise, the symbolic link
-              is ineffective. To avoid problems, the server should not
-              be running when you move the database directory.
+              directory exists by creating it if necessary. If you
+              already have a database directory named
+              <filename>foo</filename> in the data directory, you should
+              move it to <filename>D:\data</filename>. Otherwise, the
+              symbolic link will be ineffective. To avoid problems, make
+              sure that the server is not running when you move the
+              database directory.
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/problems.xml
===================================================================
--- trunk/refman-5.0/problems.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/problems.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -4898,7 +4898,7 @@
 
         <listitem>
           <para>
-            Due to the way table definition files are stored, you cannot
+            Due to the way table format (<filename>.frm</filename>) files are stored, you cannot
             use character 255 (<literal>CHAR(255)</literal>) in table
             names, column names, or enumerations. This is scheduled to
             be fixed in version 5.1 when we implement new table

Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/renamed-nodes.txt	2006-01-17 05:24:19 UTC (rev 864)
@@ -396,3 +396,4 @@
 charset-cast charset-convert
 charset-defaults charset-syntax
 charset-config-file adding-character-set
+open-tables table-cache

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/replication.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -1112,8 +1112,8 @@
           way to take a binary snapshot of <literal>InnoDB</literal>
           tables is to shut down the master server and copy the
           <literal>InnoDB</literal> data files, log files, and table
-          definition files (<filename>.frm</filename> files). To record
-          the current log file name and offset, you should issue the
+          format files (<filename>.frm</filename> files). To record the
+          current log file name and offset, you should issue the
           following statements before you shut down the server:
         </para>
 

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -181,7 +181,9 @@
         includes <replaceable>table_options</replaceable> modifications,
         for options such as <literal>ENGINE</literal>,
         <literal>AUTO_INCREMENT</literal>, and
-        <literal>AVG_ROW_LENGTH</literal>. See
+        <literal>AVG_ROW_LENGTH</literal>. (However, <literal>ALTER
+        TABLE</literal> ignores the <literal>DATA DIRECTORY</literal>
+        and <literal>INDEX DIRECTORY</literal> table options.) See
         <xref linkend="create-table"/>.
       </para>
 
@@ -627,14 +629,6 @@
 
         <listitem>
           <para>
-            <literal>ALTER TABLE</literal> ignores the <literal>DATA
-            DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
-            table options.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             <indexterm type="function">
               <primary>CONVERT TO</primary>
             </indexterm>
@@ -9222,7 +9216,7 @@
 
         <listitem>
           <para>
-            As long as the table definition file
+            As long as the table format file
             <filename><replaceable>tbl_name</replaceable>.frm</filename>
             is valid, the table can be re-created as an empty table with
             <literal>TRUNCATE TABLE</literal>, even if the data or index

Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.0/storage-engines.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -468,10 +468,10 @@
       Each <literal>MyISAM</literal> table is stored on disk in three
       files. The files have names that begin with the table name and
       have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition. The
-      data file has an <filename>.MYD</filename>
-      (<literal>MYData</literal>) extension. The index file has an
-      <filename>.MYI</filename> (<literal>MYIndex</literal>) extension.
+      <filename>.frm</filename> file stores the table format. The data
+      file has an <filename>.MYD</filename> (<literal>MYData</literal>)
+      extension. The index file has an <filename>.MYI</filename>
+      (<literal>MYIndex</literal>) extension.
     </para>
 
     <para>
@@ -1654,7 +1654,7 @@
       When you create a <literal>MERGE</literal> table, MySQL creates
       two files on disk. The files have names that begin with the table
       name and have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition, and an
+      <filename>.frm</filename> file stores the table format, and an
       <filename>.MRG</filename> file contains the names of the tables
       that should be used as one. The tables do not have to be in the
       same database as the <literal>MERGE</literal> table itself.
@@ -2810,8 +2810,8 @@
         Each <literal>BDB</literal> table is stored on disk in two
         files. The files have names that begin with the table name and
         have an extension to indicate the file type. An
-        <filename>.frm</filename> file stores the table definition, and
-        a <filename>.db</filename> file contains the table data and
+        <filename>.frm</filename> file stores the table format, and a
+        <filename>.db</filename> file contains the table data and
         indexes.
       </para>
 
@@ -3285,11 +3285,10 @@
 
     <para>
       When you create an <literal>EXAMPLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table. Retrievals return an empty
-      result.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. No other files are created. No data can be stored into
+      the table. Retrievals return an empty result.
     </para>
 
 <programlisting>
@@ -3368,11 +3367,11 @@
 
       <para>
         When you create a <literal>FEDERATED</literal> table, the server
-        creates a table definition file in the database directory. The
-        file begins with the table name and has an
-        <filename>.frm</filename> extension. No other files are created,
-        because the actual data is in a remote table. This differs from
-        the way that storage engines for local tables work.
+        creates a table format file in the database directory. The file
+        begins with the table name and has an <filename>.frm</filename>
+        extension. No other files are created, because the actual data
+        is in a remote table. This differs from the way that storage
+        engines for local tables work.
       </para>
 
       <para>
@@ -3738,14 +3737,14 @@
 
     <para>
       When you create an <literal>ARCHIVE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. The storage engine creates
-      other files, all having names beginning with the table name. The
-      data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>,
-      respectively. An <filename>.ARN</filename> file may appear during
-      optimization operations.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. The storage engine creates other files, all having
+      names beginning with the table name. The data and metadata files
+      have extensions of <filename>.ARZ</filename> and
+      <filename>.ARM</filename>, respectively. An
+      <filename>.ARN</filename> file may appear during optimization
+      operations.
     </para>
 
     <para>
@@ -3876,7 +3875,7 @@
 
     <para>
       When you create a <literal>CSV</literal> table, the server creates
-      a table definition file in the database directory. The file begins
+      a table format file in the database directory. The file begins
       with the table name and has an <filename>.frm</filename>
       extension. The storage engine also creates a data file. Its name
       begins with the table name and has a <filename>.CSV</filename>
@@ -3971,10 +3970,9 @@
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. There are no other files
-      associated with the table.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. There are no other files associated with the table.
     </para>
 
     <para>

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/optimization.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -2760,7 +2760,7 @@
               The criteria for when this happens are too complicated to
               be specified here. So maybe it is worth adding a phrase
               "so if you need to figure out #key parts used, better use
-              logic described then simply rely in key_len value."
+              logic described than simply rely on key_len value."
             </remark>
           </listitem>
 
@@ -6023,10 +6023,9 @@
       <para>
         <literal>InnoDB</literal> uses row locks and
         <literal>BDB</literal> uses page locks. For these two storage
-        engines, deadlocks are possible. This occurs because
-        <literal>InnoDB</literal> automatically acquires row locks and
-        <literal>BDB</literal> acquires page locks during the processing
-        of SQL statements, not at the start of the transaction.
+        engines, deadlocks are possible because they automatically
+        acquire locks during the processing of SQL statements, not at
+        the start of the transaction.
       </para>
 
       <para>
@@ -6050,7 +6049,7 @@
 
         <listitem>
           <para>
-            Makes it possible to lock a single row for a long time.
+            Possible to lock a single row for a long time.
           </para>
         </listitem>
 
@@ -6064,34 +6063,26 @@
 
         <listitem>
           <para>
-            Takes more memory than page-level or table-level locks.
+            Requires more memory than page-level or table-level locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is slower than page-level or table-level locks when used on
-            a large part of the table because you must acquire many more
+            Slower than page-level or table-level locks when used on a
+            large part of the table because you must acquire many more
             locks.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Is definitely much slower than other locks if you often do
+            Definitely much slower than other locks if you often do
             <literal>GROUP BY</literal> operations on a large part of
-            the data or if you often must scan the entire table.
+            the data or if you must scan the entire table frequently.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            With higher-level locks, you can also more easily tune
-            applications by supporting locks of different types, because
-            the lock overhead is less than for row-level locks.
-          </para>
-        </listitem>
-
       </itemizedlist>
 
       <para>
@@ -6109,8 +6100,9 @@
 
         <listitem>
           <para>
-            Reads and updates on strict keys, where you update or delete
-            a row that can be fetched with a single key read:
+            A mix of reads and writes, where writes are updates or
+            deletes for a single row that can be fetched with one key
+            read:
           </para>
 
 <programlisting>
@@ -6138,6 +6130,12 @@
       </itemizedlist>
 
       <para>
+        With higher-level locks, you can more easily tune applications
+        by supporting locks of different types, because the lock
+        overhead is less than for row-level locks.
+      </para>
+
+      <para>
         Options other than row-level or page-level locking:
       </para>
 
@@ -6206,33 +6204,44 @@
 
       <para>
         For large tables, table locking is much better than row locking
-        for most applications, but there are some pitfalls.
+        for most applications, but there are some pitfalls:
       </para>
 
-      <para>
-        Table locking enables many threads to read from a table at the
-        same time, but if a thread wants to write to a table, it must
-        first get exclusive access. During the update, all other threads
-        that want to access this particular table must wait until the
-        update is done.
-      </para>
+      <itemizedlist>
 
-      <para>
-        Table updates normally are considered to be more important than
-        table retrievals, so they are given higher priority. This should
-        ensure that updates to a table are not <quote>starved</quote>
-        even if there is heavy <literal>SELECT</literal> activity for
-        the table.
-      </para>
+        <listitem>
+          <para>
+            Table locking enables many threads to read from a table at
+            the same time, but if a thread wants to write to a table, it
+            must first get exclusive access. During the update, all
+            other threads that want to access this particular table must
+            wait until the update is done.
+          </para>
+        </listitem>
 
-      <para>
-        Table locking causes problems in cases such as when a thread is
-        waiting because the disk is full and free space needs to become
-        available before the thread can proceed. In this case, all
-        threads that want to access the problem table are also put in a
-        waiting state until more disk space is made available.
-      </para>
+        <listitem>
+          <para>
+            Table updates normally are considered to be more important
+            than table retrievals, so they are given higher priority.
+            This should ensure that updates to a table are not
+            <quote>starved</quote> even if there is heavy
+            <literal>SELECT</literal> activity for the table.
+          </para>
+        </listitem>
 
+        <listitem>
+          <para>
+            Table locking causes problems in cases such as when a thread
+            is waiting because the disk is full and free space needs to
+            become available before the thread can proceed. In this
+            case, all threads that want to access the problem table are
+            also put in a waiting state until more disk space is made
+            available.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
       <para>
         Table locking is also disadvantageous under the following
         scenario:
@@ -6270,7 +6279,7 @@
       </itemizedlist>
 
       <para>
-        The following list describes some ways to avoid or reduce
+        The following items describe some ways to avoid or reduce
         contention caused by table locking:
       </para>
 
@@ -6279,8 +6288,8 @@
         <listitem>
           <para>
             Try to get the <literal>SELECT</literal> statements to run
-            faster. You might have to create some summary tables to do
-            this.
+            faster so that they lock tables for a shorter time. You
+            might have to create some summary tables to do this.
           </para>
         </listitem>
 
@@ -6399,9 +6408,9 @@
         <listitem>
           <para>
             You can use <literal>LOCK TABLES</literal> to increase
-            speed, as many updates within a single lock is much faster
-            than updating without locks. Splitting table contents into
-            separate tables may also help.
+            speed, because many updates within a single lock is much
+            faster than updating without locks. Splitting table contents
+            into separate tables may also help.
           </para>
         </listitem>
 
@@ -6543,11 +6552,11 @@
 
       <para>
         One of the most basic optimizations is to design your tables to
-        take as little space on the disk as possible. This can give huge
-        improvements because disk reads are faster, and smaller tables
-        normally require less main memory while their contents are being
-        actively processed during query execution. Indexing also is a
-        lesser resource burden if done on smaller columns.
+        take as little space on the disk as possible. This can result in
+        huge improvements because disk reads are faster, and smaller
+        tables normally require less main memory while their contents
+        are being actively processed during query execution. Indexing
+        also is a lesser resource burden if done on smaller columns.
       </para>
 
       <para>
@@ -6559,8 +6568,8 @@
       </para>
 
       <para>
-        You can get better performance on a table and minimize storage
-        space using the techniques listed here:
+        You can get better performance for a table and minimize storage
+        space by using the techniques listed here:
       </para>
 
       <itemizedlist>
@@ -6569,13 +6578,8 @@
           <para>
             Use the most efficient (smallest) data types possible. MySQL
             has many specialized types that save disk space and memory.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Use the smaller integer types if possible to get smaller
-            tables. For example, <literal>MEDIUMINT</literal> is often a
+            For example, use the smaller integer types if possible to
+            get smaller tables. <literal>MEDIUMINT</literal> is often a
             better choice than <literal>INT</literal> because a
             <literal>MEDIUMINT</literal> column uses 25% less space.
           </para>
@@ -6600,16 +6604,15 @@
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
-            <literal>VARCHAR</literal> columns with the
-            <literal>CREATE</literal> option
-            <literal>ROW_FORMAT=fixed</literal>.
+            <literal>VARCHAR</literal> columns with the <literal>CREATE
+            TABLE</literal> option <literal>ROW_FORMAT=FIXED</literal>.
           </para>
         </listitem>
 
         <listitem>
           <para>
             <literal>InnoDB</literal> tables use a compact storage
-            format. Versions of MySQL prior to 5.0.3,
+            format. In versions of MySQL earlier than 5.0.3,
             <literal>InnoDB</literal> rows contain some redundant
             information, such as the number of columns and the length of
             each column, even for fixed-size columns. By default, tables
@@ -6621,21 +6624,21 @@
 
           <para>
             The compact <literal>InnoDB</literal> format also changes
-            the way how <literal>CHAR</literal> columns containing UTF-8
-            data are stored. In the
-            <literal>ROW_FORMAT=REDUNDANT</literal> format, a UTF-8
-            <literal>CHAR(<replaceable>n</replaceable>)</literal>
-            occupies 3*<replaceable>n</replaceable> bytes, given that
-            the maximum length of a UTF-8 encoded character is 3 bytes.
-            Many languages can be written mostly with single-byte UTF-8
-            characters, so a fixed storage length often wastes space.
-            The <literal>ROW_FORMAT=COMPACT</literal> format allocates a
-            variable amount of
-            <replaceable>n</replaceable>..3*<replaceable>n</replaceable>
-            bytes for these columns by stripping trailing spaces if
-            necessary. The minimum storage length is kept as
-            <replaceable>n</replaceable> bytes in order to facilitate
-            in-place updates in typical cases.
+            how <literal>CHAR</literal> columns containing UTF-8 data
+            are stored. With <literal>ROW_FORMAT=REDUNDANT</literal>, a
+            UTF-8 <literal>CHAR(<replaceable>N</replaceable>)</literal>
+            occupies 3 &times; <replaceable>N</replaceable> bytes, given
+            that the maximum length of a UTF-8 encoded character is
+            three bytes. Many languages can be written primarily using
+            single-byte UTF-8 characters, so a fixed storage length
+            often wastes space. With
+            <literal>ROW_FORMAT=COMPACT</literal> format,
+            <literal>InnoDB</literal> allocates a variable amount of
+            storage in the range from <replaceable>N</replaceable> to 3
+            &times; <replaceable>N</replaceable> bytes for these columns
+            by stripping trailing spaces if necessary. The minimum
+            storage length is kept as <replaceable>N</replaceable> bytes
+            in order to facilitate in-place updates in typical cases.
           </para>
         </listitem>
 
@@ -6651,7 +6654,7 @@
             Create only the indexes that you really need. Indexes are
             good for retrieval but bad when you need to store data
             quickly. If you access a table mostly by searching on a
-            combination of columns, make an index on them. The first
+            combination of columns, create an index on them. The first
             part of the index should be the column most used. If you
             <emphasis>always</emphasis> use many columns when selecting
             from the table, you should use the column with more
@@ -6661,15 +6664,14 @@
 
         <listitem>
           <para>
-            If it is very likely that a column has a unique prefix on
-            the first number of characters, it's better to index only
-            this prefix, using MySQL's support for creating an index on
-            the leftmost part of a character column (see
-            <xref linkend="create-index"/>). Shorter indexes are faster
-            &mdash; not only because they require less disk space
-            &mdash; but because they give also you more hits in the
-            index cache, and thus fewer disk seeks. See
-            <xref linkend="server-parameters"/>.
+            If it is very likely that a string column has a unique
+            prefix on the first number of characters, it's better to
+            index only this prefix, using MySQL's support for creating
+            an index on the leftmost part of the column (see
+            <xref linkend="create-index"/>). Shorter indexes are faster,
+            not only because they require less disk space, but because
+            they give also you more hits in the index cache, and thus
+            fewer disk seeks. See <xref linkend="server-parameters"/>.
           </para>
         </listitem>
 
@@ -6677,7 +6679,7 @@
           <para>
             In some circumstances, it can be beneficial to split into
             two a table that is scanned very often. This is especially
-            true if it is a dynamic format table and it is possible to
+            true if it is a dynamic-format table and it is possible to
             use a smaller static format table that can be used to find
             the relevant rows when scanning the table.
           </para>
@@ -6719,16 +6721,6 @@
         least 256 bytes. Most storage engines have higher limits.
       </para>
 
-      <para>
-        With
-        <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
-        syntax in an index specification, you can create an index that
-        uses only the first <replaceable>length</replaceable> characters
-        of a <literal>CHAR</literal> or <literal>VARCHAR</literal>
-        column. Indexing only a prefix of column values in this way can
-        make the index file much smaller.
-      </para>
-
       <indexterm>
         <primary><literal>BLOB</literal> columns</primary>
         <secondary>indexing</secondary>
@@ -6750,9 +6742,12 @@
       </indexterm>
 
       <para>
-        The <literal>MyISAM</literal> and <literal>InnoDB</literal>
-        storage engines also support indexing on <literal>BLOB</literal>
-        and <literal>TEXT</literal> columns. When indexing a
+        With
+        <literal><replaceable>col_name</replaceable>(<replaceable>N</replaceable>)</literal>
+        syntax in an index specification, you can create an index that
+        uses only the first <replaceable>N</replaceable> characters of a
+        string column. Indexing only a prefix of column values in this
+        way can make the index file much smaller. When you index a
         <literal>BLOB</literal> or <literal>TEXT</literal> column, you
         <emphasis>must</emphasis> specify a prefix length for the index.
         For example:
@@ -6779,19 +6774,21 @@
         <literal>FULLTEXT</literal> indexes and only for
         <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
         <literal>TEXT</literal> columns. Indexing always takes place
-        over the entire column and partial (prefix) indexing is not
-        supported. See <xref linkend="fulltext-search"/>, for details.
+        over the entire column and partial (column prefix) indexing is
+        not supported. For details, see
+        <xref linkend="fulltext-search"/>.
       </para>
 
       <para>
-        You can also create indexes on spatial data types. Spatial types
-        are supported only by the <literal>MyISAM</literal> storage
-        engine. Spatial indexes use R-trees.
+        You can also create indexes on spatial data types. Spatial
+        indexes use R-trees. Currently, only <literal>MyISAM</literal>
+        supports indexes on spatial types.
       </para>
 
       <para>
-        The <literal>MEMORY</literal> storage engine uses hash indexes
-        by default, but also supports B-tree indexes.
+        The <literal>MEMORY</literal> storage engine uses
+        <literal>HASH</literal> indexes by default, but also supports
+        <literal>BTREE</literal> indexes.
       </para>
 
     </section>
@@ -6815,9 +6812,10 @@
       </indexterm>
 
       <para>
-        MySQL can create indexes on multiple columns. An index may
-        consist of up to 15 columns. For certain data types, you can
-        index a prefix of the column (see <xref linkend="indexes"/>).
+        MySQL can create composite indexes (that is, indexes on multiple
+        columns). An index may consist of up to 15 columns. For certain
+        data types, you can index a prefix of the column (see
+        <xref linkend="indexes"/>).
       </para>
 
       <para>
@@ -6848,11 +6846,11 @@
 </programlisting>
 
       <para>
-        The <literal>name</literal> index is an index over
+        The <literal>name</literal> index is an index over the
+        <literal>last_name</literal> and <literal>first_name</literal>
+        columns. The index can be used for queries that specify values
+        in a known range for <literal>last_name</literal>, or for both
         <literal>last_name</literal> and <literal>first_name</literal>.
-        The index can be used for queries that specify values in a known
-        range for <literal>last_name</literal>, or for both
-        <literal>last_name</literal> and <literal>first_name</literal>.
         Therefore, the <literal>name</literal> index is used in the
         following queries:
       </para>
@@ -6910,9 +6908,8 @@
         determine the position to seek to in the middle of the data file
         without having to look at all the data. If a table has 1,000
         rows, this is at least 100 times faster than reading
-        sequentially. Note that if you need to access most of the rows,
-        it is faster to read sequentially, because this minimizes disk
-        seeks.
+        sequentially. If you need to access most of the rows, it is
+        faster to read sequentially, because this minimizes disk seeks.
       </para>
 
       <para>
@@ -6936,7 +6933,7 @@
       </para>
 
       <para>
-        Indexes are used for these operations:
+        MySQL uses indexes for these operations:
       </para>
 
       <itemizedlist>
@@ -6968,12 +6965,12 @@
             <literal>MAX()</literal> value for a specific indexed column
             <replaceable>key_col</replaceable>. This is optimized by a
             preprocessor that checks whether you are using
-            <literal>WHERE <replaceable>key_part_#</replaceable> =
+            <literal>WHERE <replaceable>key_part_N</replaceable> =
             <replaceable>constant</replaceable></literal> on all key
             parts that occur before <replaceable>key_col</replaceable>
             in the index. In this case, MySQL does a single key lookup
             for each <literal>MIN()</literal> or
-            <literal>MAX()</literal> expression and replace it with a
+            <literal>MAX()</literal> expression and replaces it with a
             constant. If all expressions are replaced with constants,
             the query returns at once. For example:
           </para>
@@ -7019,7 +7016,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;</userinput>
+mysql&gt; <userinput>SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;</userinput>
 </programlisting>
 
       <para>
@@ -7057,11 +7054,11 @@
       </para>
 
 <programlisting>
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=val1 AND col2=val2;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col1=<replaceable>val1</replaceable> AND col2=<replaceable>val2</replaceable>;
 
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2;
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=val2 AND col3=val3;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable>;
+SELECT * FROM <replaceable>tbl_name</replaceable> WHERE col2=<replaceable>val2</replaceable> AND col3=<replaceable>val3</replaceable>;
 </programlisting>
 
       <para>
@@ -7307,9 +7304,9 @@
 
       <para>
         This section first describes the basic operation of the
-        <literal>MyISAM</literal> key cache. Then it discusses recent
-        changes that improve key cache performance and that enable you
-        to better control cache operation:
+        <literal>MyISAM</literal> key cache. Then it discusses features
+        that improve key cache performance and that enable you to better
+        control cache operation:
       </para>
 
       <itemizedlist>
@@ -7330,7 +7327,7 @@
       </itemizedlist>
 
       <para>
-        You can control the size of the key cache by means of the
+        To control the size of the key cache, use the
         <literal>key_buffer_size</literal> system variable. If this
         variable is set equal to zero, no key cache is used. The key
         cache also is not used if the <literal>key_buffer_size</literal>
@@ -7446,9 +7443,8 @@
           not eliminate contention among threads entirely. They still
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
-          MySQL &current-series; also provides multiple key caches,
-          which enables you to assign different table indexes to
-          different key caches.
+          MySQL also provides multiple key caches. This feature enables
+          you to assign different table indexes to different key caches.
         </para>
 
         <para>
@@ -7458,12 +7454,9 @@
           <literal>MyISAM</literal> table indexes are cached in the
           default key cache. To assign table indexes to a specific key
           cache, use the <literal>CACHE INDEX</literal> statement (see
-          <xref linkend="cache-index"/>).
-        </para>
-
-        <para>
-          For example, the following statement assigns indexes from the
-          tables <literal>t1</literal>, <literal>t2</literal>, and
+          <xref linkend="cache-index"/>). For example, the following
+          statement assigns indexes from the tables
+          <literal>t1</literal>, <literal>t2</literal>, and
           <literal>t3</literal> to the key cache named
           <literal>hot_cache</literal>:
         </para>
@@ -7504,7 +7497,7 @@
         </para>
 
 <programlisting>
-mysql&gt; <userinput>set global key_buffer_size = 0;</userinput>
+mysql&gt; <userinput>SET GLOBAL key_buffer_size = 0;</userinput>
 
 mysql&gt; <userinput>show variables like 'key_buffer_size';</userinput>
 +-----------------+---------+
@@ -7638,8 +7631,8 @@
         </para>
 
 <programlisting>
-CACHE INDEX a.t1, a.t2, b.t3 IN hot_cache
-CACHE INDEX a.t4, b.t5, b.t6 IN cold_cache
+CACHE INDEX db1.t1, db1.t2, db2.t3 IN hot_cache
+CACHE INDEX db1.t4, db2.t5, db2.t6 IN cold_cache
 </programlisting>
 
       </section>
@@ -7652,7 +7645,7 @@
           By default, the key cache management system uses the LRU
           strategy for choosing key cache blocks to be evicted, but it
           also supports a more sophisticated method called the
-          <quote>midpoint insertion strategy.</quote>
+          <firstterm>midpoint insertion strategy.</firstterm>
         </para>
 
         <para>
@@ -7702,7 +7695,7 @@
           The threshold value prescribes that, for a key cache
           containing <replaceable>N</replaceable> blocks, the block at
           the beginning of the hot sub-chain not accessed within the
-          last <literal><replaceable>N</replaceable> *
+          last <literal><replaceable>N</replaceable> &times;
           key_cache_age_threshold / 100</literal> hits is to be moved to
           the beginning of the warm sub-chain. It then becomes the first
           candidate for eviction, because blocks for replacement always
@@ -8058,7 +8051,8 @@
 
         <listitem>
           <para>
-            Execute <command>myisamchk --stats_method=method_name
+            Execute <command>myisamchk
+            --stats_method=<replaceable>method_name</replaceable>
             --analyze</command>
           </para>
         </listitem>
@@ -8109,12 +8103,40 @@
 
     </section>
 
-    <section id="open-tables">
+    <section id="table-cache">
 
-      <title>&title-open-tables;</title>
+      <title>&title-table-cache;</title>
 
+      <indexterm type="function">
+        <primary>table_open_cache</primary>
+      </indexterm>
+
       <indexterm>
         <primary>tables</primary>
+        <secondary>opening</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
+        <secondary>closing</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>opening</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>closing</primary>
+        <secondary>tables</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>table cache</primary>
+      </indexterm>
+
+      <indexterm>
+        <primary>tables</primary>
         <secondary>open</secondary>
       </indexterm>
 
@@ -8150,45 +8172,6 @@
       </para>
 
       <para>
-        You can read more about this topic in the next section. See
-        <xref linkend="table-cache"/>.
-      </para>
-
-    </section>
-
-    <section id="table-cache">
-
-      <title>&title-table-cache;</title>
-
-      <indexterm type="function">
-        <primary>table_open_cache</primary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>opening</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>tables</primary>
-        <secondary>closing</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>opening</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>closing</primary>
-        <secondary>tables</secondary>
-      </indexterm>
-
-      <indexterm>
-        <primary>table cache</primary>
-      </indexterm>
-
-      <para>
         The <literal>table_open_cache</literal>,
         <literal>max_connections</literal>, and
         <literal>max_tmp_tables</literal> system variables affect the
@@ -8206,10 +8189,10 @@
         <literal>table_open_cache</literal> is related to
         <literal>max_connections</literal>. For example, for 200
         concurrent running connections, you should have a table cache
-        size of at least <literal>200 *
+        size of at least <literal>200 &times;
         <replaceable>N</replaceable></literal>, where
         <replaceable>N</replaceable> is the maximum number of tables per
-        join in any of the queries which you execute. You also need to
+        join in any of the queries which you execute. You must also
         reserve some extra file descriptors for temporary tables and
         files.
       </para>
@@ -8239,8 +8222,8 @@
       </para>
 
       <para>
-        An unused table is closed and removed from the table cache under
-        the following circumstances:
+        MySQL closes an unused table and removes it from the table cache
+        under the following circumstances:
       </para>
 
       <itemizedlist>
@@ -8315,10 +8298,10 @@
         table or if a thread accesses the table twice in the same query
         (for example, by joining the table to itself). Each concurrent
         open requires an entry in the table cache. The first open of any
-        table takes two file descriptors: one for the data file and one
-        for the index file. Each additional use of the table takes only
-        one file descriptor for the data file. The index file descriptor
-        is shared among all threads.
+        <literal>MyISAM</literal> table takes two file descriptors: one
+        for the data file and one for the index file. Each additional
+        use of the table takes only one file descriptor for the data
+        file. The index file descriptor is shared among all threads.
       </para>
 
       <para>
@@ -8412,7 +8395,7 @@
         decisions must be made very early to achieve large performance
         gains. In other cases, a quick look at this section may suffice.
         However, it is always nice to have a sense of how much can be
-        gained by changing things at this level.
+        gained by changing factors that apply at this level.
       </para>
 
       <para>
@@ -8452,37 +8435,38 @@
 
         <listitem>
           <para>
-            Use the <option>--skip-external-locking</option> MySQL
-            option to avoid external locking. This option is on by
-            default.
+            Avoid external locking. Since MySQL 4.0, the default has
+            been for external locking to be disabled on all systems. The
+            <option>--external-locking</option> and
+            <option>--skip-external-locking</option> options explicitly
+            enable and disable external locking.
           </para>
 
           <para>
-            Note that the <option>--skip-external-locking</option>
-            option does not affect MySQL's functionality as long as you
-            run only one server. Just remember to take down the server
-            (or lock and flush the relevant tables) before you run
-            <command>myisamchk</command>. On some systems this option is
-            mandatory, because the external locking does not work in any
-            case.
+            Note that disabling external locking does not affect MySQL's
+            functionality as long as you run only one server. Just
+            remember to take down the server (or lock and flush the
+            relevant tables) before you run
+            <command>myisamchk</command>. On some systems it is
+            mandatory to disable external locking because it does not
+            work, anyway.
           </para>
 
           <para>
-            The only case in which you cannot use
-            <option>--skip-external-locking</option> is if you run
-            multiple MySQL <emphasis>servers</emphasis> (not clients) on
-            the same data, or if you run <command>myisamchk</command> to
-            check (not repair) a table without telling the server to
-            flush and lock the tables first. Note that using multiple
-            MySQL servers to access the same data concurrently is
-            generally <emphasis>not</emphasis> recommended, except when
-            using MySQL Cluster.
+            The only case in which you cannot disable external locking
+            is when you run multiple MySQL <emphasis>servers</emphasis>
+            (not clients) on the same data, or if you run
+            <command>myisamchk</command> to check (not repair) a table
+            without telling the server to flush and lock the tables
+            first. Note that using multiple MySQL servers to access the
+            same data concurrently is generally <emphasis>not</emphasis>
+            recommended, except when using MySQL Cluster.
           </para>
 
           <para>
-            You can still use <literal>LOCK TABLES</literal> and
-            <literal>UNLOCK TABLES</literal> even if you are using
-            <option>--skip-external-locking</option>.
+            The <literal>LOCK TABLES</literal> and <literal>UNLOCK
+            TABLES</literal> statements use internal locking, so you can
+            use them even if external locking is disabled.
           </para>
         </listitem>
 
@@ -8787,8 +8771,8 @@
 
       <para>
         If there is a <command>mysqld</command> server currently
-        running, you can see what values it actually is using for the
-        system variables by connecting to it and issuing this statement:
+        running, you can see the current values of its system variables
+        by connecting to it and issuing this statement:
       </para>
 
 <programlisting>
@@ -8815,8 +8799,8 @@
 </programlisting>
 
       <para>
-        You can find a full description for all system and status
-        variables in <xref linkend="server-system-variables"/>, and
+        For a full description for all system and status variables, see
+        <xref linkend="server-system-variables"/>, and
         <xref linkend="server-status-variables"/>.
       </para>
 
@@ -8921,11 +8905,12 @@
         <filename>my-large.cnf</filename>,
         <filename>my-medium.cnf</filename>, and
         <filename>my-small.cnf</filename>. You can use these as a basis
-        for optimizing your system.
+        for optimizing your system. (On Windows, look in the MySQL
+        installation directory.)
       </para>
 
       <para>
-        Note that if you specify an option on the command line for
+        If you specify an option on the command line for
         <command>mysqld</command> or <command>mysqld_safe</command>, it
         remains in effect only for that invocation of the server. To use
         the option every time the server runs, put it in an option file.
@@ -9005,13 +8990,13 @@
             shows that this kind of <quote>educated guess</quote> rarely
             misses optimal plans, and may dramatically reduce query
             compilation times. That is why this option is on
-            (<literal>optimizer_prune_level</literal>=1) by default.
+            (<literal>optimizer_prune_level=1</literal>) by default.
             However, if you believe that the optimizer missed a better
             query plan, this option can be switched off
-            (<literal>optimizer_prune_level</literal>=0) with the risk
-            that query compilation may take much longer. Notice that
-            even with the use of this heuristic, the optimizer still
-            explores a roughly exponential number of plans.
+            (<literal>optimizer_prune_level=0</literal>) with the risk
+            that query compilation may take much longer. Note that, even
+            with the use of this heuristic, the optimizer still explores
+            a roughly exponential number of plans.
           </para>
         </listitem>
 
@@ -9286,7 +9271,7 @@
 
             <listitem>
               <para>
-                A stack (default 64KB, variable
+                A stack (default 192KB, variable
                 <literal>thread_stack</literal>)
               </para>
             </listitem>
@@ -9357,10 +9342,10 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>MEMORY</literal>) tables.
-            Temporary tables with a large row length (calculated as the
-            sum of all column lengths) or that contain
-            <literal>BLOB</literal> columns are stored on disk.
+            tables are memory-based hash tables. Temporary tables with a
+            large row length (calculated as the sum of all column
+            lengths) or that contain <literal>BLOB</literal> columns are
+            stored on disk.
           </para>
 
           <para>
@@ -9389,7 +9374,7 @@
             Almost all parsing and calculating is done in a local memory
             store. No memory overhead is needed for small items, so the
             normal slow memory allocation and freeing is avoided. Memory
-            is allocated only for unexpectedly large strings; this is
+            is allocated only for unexpectedly large strings. This is
             done with <literal>malloc()</literal> and
             <literal>free()</literal>.
           </para>
@@ -9401,7 +9386,7 @@
             index file is opened once; the data file is opened once for
             each concurrently running thread. For each concurrent
             thread, a table structure, column structures for each
-            column, and a buffer of size <literal>3 *
+            column, and a buffer of size <literal>3 &times;
             <replaceable>N</replaceable></literal> are allocated (where
             <replaceable>N</replaceable> is the maximum row length, not
             counting <literal>BLOB</literal> columns). A
@@ -9528,7 +9513,7 @@
       </para>
 
       <para>
-        If you want to disallow TCP/IP connections entirely, start
+        To disallow TCP/IP connections entirely, start
         <command>mysqld</command> with the
         <option>--skip-networking</option> option.
       </para>
@@ -9601,14 +9586,15 @@
             <para>
               Striping means that you have many disks and put the first
               block on the first disk, the second block on the second
-              disk, and the <replaceable>N</replaceable>th block on the
-              (<literal><replaceable>N</replaceable> mod
-              number_of_disks</literal>) disk, and so on. This means if
-              your normal data size is less than the stripe size (or
-              perfectly aligned), you get much better performance.
-              Striping is very dependent on the operating system and the
-              stripe size, so benchmark your application with different
-              stripe sizes. See <xref linkend="custom-benchmarks"/>.
+              disk, and the <replaceable>N</replaceable>-th block on the
+              (<literal><replaceable>N</replaceable> MOD
+              <replaceable>number_of_disks</replaceable></literal>)
+              disk, and so on. This means if your normal data size is
+              less than the stripe size (or perfectly aligned), you get
+              much better performance. Striping is very dependent on the
+              operating system and the stripe size, so benchmark your
+              application with different stripe sizes. See
+              <xref linkend="custom-benchmarks"/>.
             </para>
 
             <para>
@@ -9626,11 +9612,13 @@
 
       <listitem>
         <para>
-          For reliability you may want to use RAID 0+1 (striping plus
-          mirroring), but in this case, you need 2*N drives to hold N
-          drives of data. This is probably the best option if you have
-          the money for it. However, you may also have to invest in some
-          volume-management software to handle it efficiently.
+          For reliability, you may want to use RAID 0+1 (striping plus
+          mirroring), but in this case, you need 2 &times;
+          <replaceable>N</replaceable> drives to hold
+          <replaceable>N</replaceable> drives of data. This is probably
+          the best option if you have the money for it. However, you may
+          also have to invest in some volume-management software to
+          handle it efficiently.
         </para>
       </listitem>
 
@@ -9640,9 +9628,9 @@
           critical a type of data is. For example, store semi-important
           data that can be regenerated on a RAID 0 disk, but store
           really important data such as host information and logs on a
-          RAID 0+1 or RAID N disk. RAID N can be a problem if you have
-          many writes, due to the time required to update the parity
-          bits.
+          RAID 0+1 or RAID <replaceable>N</replaceable> disk. RAID
+          <replaceable>N</replaceable> can be a problem if you have many
+          writes, due to the time required to update the parity bits.
         </para>
       </listitem>
 
@@ -9757,12 +9745,12 @@
 </programlisting>
 
         <para>
-          For any table <literal>tbl_a</literal> in
+          The result is that, or any table <literal>tbl_a</literal> in
           <literal>db1</literal>, there also appears to be a table
           <literal>tbl_a</literal> in <literal>db2</literal>. If one
           client updates <literal>db1.tbl_a</literal> and another client
           updates <literal>db2.tbl_a</literal>, problems are likely to
-          result.
+          occur.
         </para>
 
         <para>
@@ -9785,11 +9773,6 @@
 if (1)
 </programlisting>
 
-        <para>
-          Note that symbolic link support is enabled by default for all
-          Windows servers.
-        </para>
-
       </section>
 
       <section id="symbolic-links-to-tables">
@@ -9810,16 +9793,11 @@
           statement.
         </para>
 
-        <remark role="todo">
-          Following paras still true for 5.1? [js] (Yes: PD)
-        </remark>
-
         <para>
           Symlinks are fully supported only for
-          <literal>MyISAM</literal> tables. For other storage engines,
-          you may get strange problems if you try to use symbolic links
-          on files in the operating system with any of the preceding
-          statements.
+          <literal>MyISAM</literal> tables. For files used by tables for
+          other storage engines, you may get strange problems if you try
+          to use symbolic links.
         </para>
 
         <para>
@@ -9831,11 +9809,12 @@
 
           <listitem>
             <para>
-              In the data directory, you always have the table
-              definition file, the data file, and the index file. The
-              data file and index file can be moved elsewhere and
-              replaced in the data directory by symlinks. The definition
-              file cannot.
+              In the data directory, you always have the table format
+              (<filename>.frm</filename>) file, the data
+              (<filename>.MYD</filename>) file, and the index
+              (<filename>.MYI</filename>) file. The data file and index
+              file can be moved elsewhere and replaced in the data
+              directory by symlinks. The format file cannot.
             </para>
           </listitem>
 
@@ -9848,14 +9827,14 @@
 
           <listitem>
             <para>
-              Symlinking can be accomplished manually from the command
-              line using <literal>ln -s</literal> if
-              <command>mysqld</command> is not running. Alternatively,
-              you can instruct a running MySQL server to perform the
+              You can instruct a running MySQL server to perform the
               symlinking by using the <literal>DATA DIRECTORY</literal>
               and <literal>INDEX DIRECTORY</literal> options to
               <literal>CREATE TABLE</literal>. See
-              <xref linkend="create-table"/>.
+              <xref linkend="create-table"/>. Alternatively, symlinking
+              can be accomplished manually from the command line using
+              <literal>ln -s</literal> if <command>mysqld</command> is
+              not running.
             </para>
           </listitem>
 
@@ -10021,40 +10000,29 @@
         </indexterm>
 
         <para>
-          The <command>mysqld-max</command> and
-          <literal>mysql-max-nt</literal> servers for Windows are
-          compiled with the <option>-DUSE_SYMDIR</option> option. This
-          allows you to put a database directory on a different disk by
-          setting up a symbolic link to it. This is similar to the way
-          that symbolic links work on Unix, although the procedure for
-          setting up the link is different.
+          Symbolic links are enabled by default for all Windows servers.
+          This enables you to put a database directory on a different
+          disk by setting up a symbolic link to it. This is similar to
+          the way that database symbolic links work on Unix, although
+          the procedure for setting up the link is different. If you do
+          not need symbolic links, you can disable them using the
+          <option>--skip-symbolic-links</option> option.
         </para>
 
         <para>
-          Symbolic links are enabled by default. If you do not need
-          them, you can disable them using the
-          <option>skip-symbolic-links</option> option:
+          On Windows, you create a symbolic link to a MySQL database by
+          creating a file in the data directory that contains the path
+          to the destination directory. The file should be named
+          <filename><replaceable>db_name</replaceable>.sym</filename>,
+          where <replaceable>db_name</replaceable> is the database name.
         </para>
 
-<programlisting>
-[mysqld]
-skip-symbolic-links
-</programlisting>
-
         <para>
-          On Windows, you can create a symbolic link to a MySQL database
-          by creating a file in the data directory that contains the
-          path to the destination directory. The file should be named
-          <filename>db_name.sym</filename>, where
-          <replaceable>db_name</replaceable> is the database name.
-        </para>
-
-        <para>
           Suppose that the MySQL data directory is
           <filename>C:\mysql\data</filename> and you want to have
           database <literal>foo</literal> located at
-          <filename>D:\data\foo</filename>. Set up a symlink as shown
-          here:
+          <filename>D:\data\foo</filename>. Set up a symlink using this
+          procedure
         </para>
 
         <orderedlist>
@@ -10062,12 +10030,13 @@
           <listitem>
             <para>
               Make sure that the <filename>D:\data\foo</filename>
-              directory exists by creating it if necessary. If you have
-              a database directory named <filename>foo</filename> in the
-              data directory, you should move it to
-              <filename>D:\data</filename>. Otherwise, the symbolic link
-              is ineffective. To avoid problems, the server should not
-              be running when you move the database directory.
+              directory exists by creating it if necessary. If you
+              already have a database directory named
+              <filename>foo</filename> in the data directory, you should
+              move it to <filename>D:\data</filename>. Otherwise, the
+              symbolic link will be ineffective. To avoid problems, make
+              sure that the server is not running when you move the
+              database directory.
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/problems.xml
===================================================================
--- trunk/refman-5.1/problems.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/problems.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -4879,7 +4879,7 @@
 
         <listitem>
           <para>
-            Due to the way table definition files are stored, you cannot
+            Due to the way table format (<filename>.frm</filename>) files are stored, you cannot
             use character 255 (<literal>CHAR(255)</literal>) in table
             names, column names, or enumerations. This is scheduled to
             be fixed in version 5.1 when we implement new table

Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/renamed-nodes.txt	2006-01-17 05:24:19 UTC (rev 864)
@@ -100,3 +100,4 @@
 charset-cast charset-convert
 charset-defaults charset-syntax
 charset-config-file adding-character-set
+open-tables table-cache

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/replication.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -1315,8 +1315,8 @@
           way to take a binary snapshot of <literal>InnoDB</literal>
           tables is to shut down the master server and copy the
           <literal>InnoDB</literal> data files, log files, and table
-          definition files (<filename>.frm</filename> files). To record
-          the current log file name and offset, you should issue the
+          format files (<filename>.frm</filename> files). To record the
+          current log file name and offset, you should issue the
           following statements before you shut down the server:
         </para>
 

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -193,7 +193,9 @@
         includes <replaceable>table_options</replaceable> modifications,
         for options such as <literal>ENGINE</literal>,
         <literal>AUTO_INCREMENT</literal>, and
-        <literal>AVG_ROW_LENGTH</literal>. See
+        <literal>AVG_ROW_LENGTH</literal>. (However, <literal>ALTER
+        TABLE</literal> ignores the <literal>DATA DIRECTORY</literal>
+        and <literal>INDEX DIRECTORY</literal> table options.) See
         <xref linkend="create-table"/>.
       </para>
 
@@ -639,14 +641,6 @@
 
         <listitem>
           <para>
-            <literal>ALTER TABLE</literal> ignores the <literal>DATA
-            DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
-            table options.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
             <indexterm type="function">
               <primary>CONVERT TO</primary>
             </indexterm>
@@ -9781,7 +9775,7 @@
 
         <listitem>
           <para>
-            As long as the table definition file
+            As long as the table format file
             <filename><replaceable>tbl_name</replaceable>.frm</filename>
             is valid, the table can be re-created as an empty table with
             <literal>TRUNCATE TABLE</literal>, even if the data or index

Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-5.1/storage-engines.xml	2006-01-17 05:24:19 UTC (rev 864)
@@ -472,10 +472,10 @@
       Each <literal>MyISAM</literal> table is stored on disk in three
       files. The files have names that begin with the table name and
       have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition. The
-      data file has an <filename>.MYD</filename>
-      (<literal>MYData</literal>) extension. The index file has an
-      <filename>.MYI</filename> (<literal>MYIndex</literal>) extension.
+      <filename>.frm</filename> file stores the table format. The data
+      file has an <filename>.MYD</filename> (<literal>MYData</literal>)
+      extension. The index file has an <filename>.MYI</filename>
+      (<literal>MYIndex</literal>) extension.
     </para>
 
     <para>
@@ -1630,7 +1630,7 @@
       When you create a <literal>MERGE</literal> table, MySQL creates
       two files on disk. The files have names that begin with the table
       name and have an extension to indicate the file type. An
-      <filename>.frm</filename> file stores the table definition, and an
+      <filename>.frm</filename> file stores the table format, and an
       <filename>.MRG</filename> file contains the names of the tables
       that should be used as one. The tables do not have to be in the
       same database as the <literal>MERGE</literal> table itself.
@@ -2812,8 +2812,8 @@
         Each <literal>BDB</literal> table is stored on disk in two
         files. The files have names that begin with the table name and
         have an extension to indicate the file type. An
-        <filename>.frm</filename> file stores the table definition, and
-        a <filename>.db</filename> file contains the table data and
+        <filename>.frm</filename> file stores the table format, and a
+        <filename>.db</filename> file contains the table data and
         indexes.
       </para>
 
@@ -3287,11 +3287,10 @@
 
     <para>
       When you create an <literal>EXAMPLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. No other files are created.
-      No data can be stored into the table. Retrievals return an empty
-      result.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. No other files are created. No data can be stored into
+      the table. Retrievals return an empty result.
     </para>
 
 <programlisting>
@@ -3369,11 +3368,11 @@
 
       <para>
         When you create a <literal>FEDERATED</literal> table, the server
-        creates a table definition file in the database directory. The
-        file begins with the table name and has an
-        <filename>.frm</filename> extension. No other files are created,
-        because the actual data is in a remote table. This differs from
-        the way that storage engines for local tables work.
+        creates a table format file in the database directory. The file
+        begins with the table name and has an <filename>.frm</filename>
+        extension. No other files are created, because the actual data
+        is in a remote table. This differs from the way that storage
+        engines for local tables work.
       </para>
 
       <para>
@@ -3741,14 +3740,14 @@
 
     <para>
       When you create an <literal>ARCHIVE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. The storage engine creates
-      other files, all having names beginning with the table name. The
-      data and metadata files have extensions of
-      <filename>.ARZ</filename> and <filename>.ARM</filename>,
-      respectively. An <filename>.ARN</filename> file may appear during
-      optimization operations.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. The storage engine creates other files, all having
+      names beginning with the table name. The data and metadata files
+      have extensions of <filename>.ARZ</filename> and
+      <filename>.ARM</filename>, respectively. An
+      <filename>.ARN</filename> file may appear during optimization
+      operations.
     </para>
 
     <para>
@@ -3905,7 +3904,7 @@
 
     <para>
       When you create a <literal>CSV</literal> table, the server creates
-      a table definition file in the database directory. The file begins
+      a table format file in the database directory. The file begins
       with the table name and has an <filename>.frm</filename>
       extension. The storage engine also creates a data file. Its name
       begins with the table name and has a <filename>.CSV</filename>
@@ -4000,10 +3999,9 @@
 
     <para>
       When you create a <literal>BLACKHOLE</literal> table, the server
-      creates a table definition file in the database directory. The
-      file begins with the table name and has an
-      <filename>.frm</filename> extension. There are no other files
-      associated with the table.
+      creates a table format file in the database directory. The file
+      begins with the table name and has an <filename>.frm</filename>
+      extension. There are no other files associated with the table.
     </para>
 
     <para>

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-17 03:22:08 UTC (rev 863)
+++ trunk/refman-common/titles.en.ent	2006-01-17 05:24:19 UTC (rev 864)
@@ -1275,7 +1275,6 @@
 <!ENTITY title-old-client "<literal>Client does not support authentication protocol</literal>">
 <!ENTITY title-open "Cursor <literal>OPEN</literal> Statement">
 <!ENTITY title-open-bugs "Open Issues in MySQL">
-<!ENTITY title-open-tables "How MySQL Counts Open Tables">
 <!ENTITY title-openbsd "OpenBSD 2.5 Notes">
 <!ENTITY title-openbsd-2-8 "OpenBSD 2.8 Notes">
 <!ENTITY title-opengis-geometry-model "The OpenGIS Geometry Model">

Thread
svn commit - mysqldoc@docsrva: r864 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-commonpaul17 Jan