List:Commits« Previous MessageNext Message »
From:paul Date:January 16 2006 8:43pm
Subject:svn commit - mysqldoc@docsrva: r857 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-16 21:43:45 +0100 (Mon, 16 Jan 2006)
New Revision: 857

Log:
 r2225@kite-hub:  paul | 2006-01-16 14:43:14 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/connector-odbc.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/optimization.xml
   trunk/refman-4.1/porting.xml
   trunk/refman-4.1/replication.xml
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-5.0/connector-odbc.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/porting.xml
   trunk/refman-5.0/replication.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.1/connector-odbc.xml
   trunk/refman-5.1/custom-engine.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/installing.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/porting.xml
   trunk/refman-5.1/replication.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-common/news-4.0.xml
   trunk/refman-common/news-connector-net.xml


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

Modified: trunk/refman-4.1/connector-odbc.xml
===================================================================
--- trunk/refman-4.1/connector-odbc.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/connector-odbc.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -1451,8 +1451,8 @@
       <para>
         In case while configuring with thread-safe option, and gotten
         into a configure error; then look at the
-        <filename>config.log</filename> and see if it is due to the lack
-        of thread-libraries in the system; and supply one with LIBS
+        <filename>config.log</filename> and see whether it is due to the
+        lack of thread-libraries in the system; and supply one with LIBS
         options i.e.
       </para>
 

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/database-administration.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -10057,8 +10057,8 @@
             users. The output of <command>mysqladmin
             processlist</command> shows the text of the currently
             executing queries, so any user who is allowed to execute
-            that command might be able to see if another user issues a
-            query such as <literal>UPDATE user SET
+            that command might be able to see whether another user
+            issues a statement such as <literal>UPDATE user SET
             password=PASSWORD('<replaceable>plaintext-password</replaceable>');</literal>.
           </para>
 
@@ -20148,11 +20148,11 @@
       </para>
 
       <para>
-         You can also change the error messages produced by the server.
-         Details can be found in the MySQL Internals manual, available at
-         <ulink url="&base-url-docs;"/>. If you upgrade to a newer
-         version of MySQL after changing the error messages, remember to
-         repeat your changes after the upgrade.
+        You can also change the error messages produced by the server.
+        Details can be found in the MySQL Internals manual, available at
+        <ulink url="&base-url-docs;"/>. If you upgrade to a newer
+        version of MySQL after changing the error messages, remember to
+        repeat your changes after the upgrade.
       </para>
 
     </section>

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/innodb.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -5323,9 +5323,9 @@
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
-        Before removing them, you might want to examine them to see if
-        they contain useful information about the cause of abnormal
-        shutdowns. Beginning with MySQL 4.0.21, the
+        Before removing them, you might want to examine them to see
+        whether they contain useful information about the cause of
+        abnormal shutdowns. Beginning with MySQL 4.0.21, the
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
         <literal>innodb_status_file=1</literal> is set.

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/installing.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -11297,8 +11297,8 @@
 
         <para>
           If the server fails to start up correctly, check the error log
-          file to see if you can find out why. Log files are located in
-          the data directory (typically
+          file to see whether you can find out why. Log files are
+          located in the data directory (typically
           <filename>C:\mysql\data</filename> on Windows,
           <filename>/usr/local/mysql/data</filename> for a Unix binary
           distribution, and <filename>/usr/local/var</filename> for a
@@ -16792,8 +16792,8 @@
             <para>
               Many applications use setuid binaries so that you need to
               specify only a single user. See the documentation provided
-              with the application to see if this is the case for your
-              application.
+              with the application to see whether this is the case for
+              your application.
             </para>
           </listitem>
 

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4523,9 +4523,10 @@
             <para>
               It is rarely necessary to increase the size of this
               buffer. If there is such a need, then it is a good idea to
-              check if the disks can actually handle the load caused by
-              database update activity. A lack of sufficient disk space
-              cannot be overcome by increasing the size of this buffer.
+              check whether the disks can actually handle the load
+              caused by database update activity. A lack of sufficient
+              disk space cannot be overcome by increasing the size of
+              this buffer.
             </para>
 
             <para>

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/optimization.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -722,7 +722,7 @@
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
         <literal>SELECT</literal> that uses indexes to find rows. You
-        can also use <literal>EXPLAIN</literal> to see whether the
+        can also use <literal>EXPLAIN</literal> to check whether the
         optimizer joins the tables in an optimal order. To force the
         optimizer to use a join order corresponding to the order in
         which the tables are named in the <literal>SELECT</literal>
@@ -937,7 +937,7 @@
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
+  WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
 </programlisting>
             </listitem>
 
@@ -972,7 +972,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1014,7 +1014,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1035,7 +1035,7 @@
 
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable>
-WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
+  WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
 </programlisting>
 
               <para>
@@ -1109,16 +1109,16 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> = 10;
+  WHERE <replaceable>key_column</replaceable> = 10;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
+  WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_column</replaceable> IN (10,20,30);
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
 </programlisting>
             </listitem>
 
@@ -1179,10 +1179,10 @@
             If this column is <literal>NULL</literal>, there are no
             relevant indexes. In this case, you may be able to improve
             the performance of your query by examining the
-            <literal>WHERE</literal> clause to see whether it refers to
-            some column or columns that would be suitable for indexing.
-            If so, create an appropriate index and check the query with
-            <literal>EXPLAIN</literal> again. See
+            <literal>WHERE</literal> clause to check whether it refers
+            to some column or columns that would be suitable for
+            indexing. If so, create an appropriate index and check the
+            query with <literal>EXPLAIN</literal> again. See
             <xref linkend="alter-table"/>.
           </para>
 
@@ -1446,10 +1446,10 @@
         of the <literal>EXPLAIN</literal> output. This should tell you
         roughly how many rows MySQL must examine to execute the query.
         If you restrict queries with the
-        <literal>max_join_size</literal> system variable, this product
-        also is used to determine which multiple-table
-        <literal>SELECT</literal> statements to execute. See
-        <xref linkend="server-parameters"/>.
+        <literal>max_join_size</literal> system variable, this row
+        product also is used to determine which multiple-table
+        <literal>SELECT</literal> statements to execute and which to
+        abort. See <xref linkend="server-parameters"/>.
       </para>
 
       <para>
@@ -1460,7 +1460,7 @@
 
       <para>
         Suppose that you have the <literal>SELECT</literal> statement
-        shown here and you plan to examine it using
+        shown here and that you plan to examine it using
         <literal>EXPLAIN</literal>:
       </para>
 
@@ -1602,9 +1602,9 @@
         Cartesian product of all the tables; that is, every combination
         of rows. This takes quite a long time, because the product of
         the number of rows in each table must be examined. For the case
-        at hand, this product is <literal>74 &times; 2135 &times; 74
-        &times; 3872 = 45,268,558,720</literal> rows. If the tables were
-        bigger, you can only imagine how long it would take.
+        at hand, this product is 74 &times; 2135 &times; 74 &times; 3872
+        = 45,268,558,720 rows. If the tables were bigger, you can only
+        imagine how long it would take.
       </para>
 
       <para>
@@ -1630,7 +1630,7 @@
 </programlisting>
 
       <para>
-        <literal>tt.ActualPC</literal> and
+        Now <literal>tt.ActualPC</literal> and
         <literal>et.EMPLOYID</literal> are both
         <literal>VARCHAR(15)</literal>. Executing the
         <literal>EXPLAIN</literal> statement again produces this result:
@@ -1651,7 +1651,7 @@
       <para>
         This is not perfect, but is much better: The product of the
         <literal>rows</literal> values is less by a factor of 74. This
-        version is executed in a couple of seconds.
+        version executes in a couple of seconds.
       </para>
 
       <para>
@@ -1667,7 +1667,8 @@
 </programlisting>
 
       <para>
-        <literal>EXPLAIN</literal> produces the output shown here:
+        After that modification, <literal>EXPLAIN</literal> produces the
+        output shown here:
       </para>
 
 <programlisting>
@@ -1681,13 +1682,10 @@
 </programlisting>
 
       <para>
-        This is almost as good as it can get.
-      </para>
-
-      <para>
-        The remaining problem is that, by default, MySQL assumes that
-        values in the <literal>tt.ActualPC</literal> column are evenly
-        distributed, and that is not the case for the
+        At this point, the query is optimized almost as well as
+        possible. The remaining problem is that, by default, MySQL
+        assumes that values in the <literal>tt.ActualPC</literal> column
+        are evenly distributed, and that is not the case for the
         <literal>tt</literal> table. Fortunately, it is easy to tell
         MySQL to analyze the key distribution:
       </para>
@@ -1696,18 +1694,9 @@
 mysql&gt; <userinput>ANALYZE TABLE tt;</userinput>
 </programlisting>
 
-<!--
-    
-<programlisting>
-shell&gt; <userinput>myisamchk -analyze PATH_TO_MYSQL_DATABASE/tt</userinput>
-shell&gt; <userinput>mysqladmin refresh</userinput>
-</programlisting>
-
--->
-
       <para>
-        The join is perfect, and <literal>EXPLAIN</literal> produces
-        this result:
+        With the additional index information, the join is perfect and
+        <literal>EXPLAIN</literal> produces this result:
       </para>
 
 <programlisting>
@@ -1724,8 +1713,10 @@
         Note that the <literal>rows</literal> column in the output from
         <literal>EXPLAIN</literal> is an educated guess from the MySQL
         join optimizer. You should check whether the numbers are even
-        close to the truth. If not, you may get better performance by
-        using <literal>STRAIGHT_JOIN</literal> in your
+        close to the truth by comparing the <literal>rows</literal>
+        product with the actual number of rows that the query returns.
+        If the numbers are quite different, you might get better
+        performance by using <literal>STRAIGHT_JOIN</literal> in your
         <literal>SELECT</literal> statement and trying to list the
         tables in a different order in the <literal>FROM</literal>
         clause.
@@ -1753,11 +1744,11 @@
       </indexterm>
 
       <para>
-        In most cases, you can estimate the performance by counting disk
-        seeks. For small tables, you can usually find a row in one disk
-        seek (because the index is probably cached). For bigger tables,
-        you can estimate that, using B-tree indexes, you need this many
-        seeks to find a row:
+        In most cases, you can estimate query performance by counting
+        disk seeks. For small tables, you can usually find a row in one
+        disk seek (because the index is probably cached). For bigger
+        tables, you can estimate that, using B-tree indexes, you need
+        this many seeks to find a row:
         <literal>log(<replaceable>row_count</replaceable>) /
         log(<replaceable>index_block_length</replaceable> / 3 &times; 2
         / (<replaceable>index_length</replaceable> +
@@ -1765,9 +1756,10 @@
       </para>
 
       <para>
-        In MySQL, an index block is usually 1024 bytes and the data
-        pointer is usually 4 bytes. For a 500,000-row table with an
-        index length of 3 bytes (medium integer), the formula indicates
+        In MySQL, an index block is usually 1,024 bytes and the data
+        pointer is usually four bytes. For a 500,000-row table with an
+        index length of three bytes (the size of
+        <literal>MEDIUMINT</literal>), the formula indicates
         <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
         <literal>4</literal> seeks.
       </para>
@@ -1781,7 +1773,7 @@
 
       <para>
         For writes, however, you need four seek requests to find where
-        to place the new index and normally two seeks to update the
+        to place a new index value and normally two seeks to update the
         index and write the row.
       </para>
 
@@ -1821,7 +1813,7 @@
         different tables should usually be done with indexes. You can
         use the <literal>EXPLAIN</literal> statement to determine which
         indexes are used for a <literal>SELECT</literal>. See
-        <xref linkend="mysql-indexes"/>, and <xref linkend="explain"/>.
+        <xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
       </para>
 
       <para>
@@ -1853,11 +1845,11 @@
           <para>
             To sort an index and data according to an index, use
             <command>myisamchk --sort-index --sort-records=1</command>
-            (if you want to sort on index 1). This is a good way to make
-            queries faster if you have a unique index from which you
-            want to read all rows in order according to the index. Note
-            that the first time you sort a large table this way, it may
-            take a long time.
+            (assuming that you want to sort on index 1). This is a good
+            way to make queries faster if you have a unique index from
+            which you want to read all rows in order according to the
+            index. Note that the first time you sort a large table this
+            way, it may take a long time.
           </para>
         </listitem>
 
@@ -1887,13 +1879,13 @@
       </para>
 
       <para>
-        Note that work on the MySQL optimizer is ongoing, so this
-        section is incomplete. MySQL performs a great many
-        optimizations, not all of which are documented here.
+        Work on the MySQL optimizer is ongoing, so this section is
+        incomplete. MySQL performs a great many optimizations, not all
+        of which are documented here.
       </para>
 
       <para>
-        Some of the optimizations performed by MySQL are listed here:
+        Some of the optimizations performed by MySQL follow:
       </para>
 
       <itemizedlist>
@@ -1962,8 +1954,9 @@
           <para>
             <literal>HAVING</literal> is merged with
             <literal>WHERE</literal> if you do not use <literal>GROUP
-            BY</literal> or group functions (<literal>COUNT()</literal>,
-            <literal>MIN()</literal>, and so on).
+            BY</literal> or aggregate functions
+            (<literal>COUNT()</literal>, <literal>MIN()</literal>, and
+            so on).
           </para>
         </listitem>
 
@@ -2018,7 +2011,7 @@
 <programlisting>
 SELECT * FROM t WHERE <replaceable>primary_key</replaceable>=1;
 SELECT * FROM t1,t2
-    WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
+  WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
 </programlisting>
         </listitem>
 
@@ -2044,8 +2037,8 @@
 
         <listitem>
           <para>
-            If you use <literal>SQL_SMALL_RESULT</literal>, MySQL uses
-            an in-memory temporary table.
+            If you use the <literal>SQL_SMALL_RESULT</literal> option,
+            MySQL uses an in-memory temporary table.
           </para>
         </listitem>
 
@@ -2054,11 +2047,11 @@
             Each table index is queried, and the best index is used
             unless the optimizer believes that it is more efficient to
             use a table scan. At one time, a scan was used based on
-            whether the best index spanned more than 30% of the table.
-            The optimizer is more complex and bases its estimate on
-            additional factors such as table size, number of rows, and
-            I/O block size, so a fixed percentage no longer determines
-            the choice between using an index or a scan.
+            whether the best index spanned more than 30% of the table,
+            but a fixed percentage no longer determines the choice
+            between using an index or a scan. The optimizer now is more
+            complex and bases its estimate on additional factors such as
+            table size, number of rows, and I/O block size.
           </para>
         </listitem>
 
@@ -2090,17 +2083,17 @@
 SELECT MIN(<replaceable>key_part1</replaceable>),MAX(<replaceable>key_part1</replaceable>) FROM <replaceable>tbl_name</replaceable>;
 
 SELECT MAX(<replaceable>key_part2</replaceable>) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
 </programlisting>
 
       <para>
-        The following queries are resolved using only the index tree,
+        MySQL resolves the following queries using only the index tree,
         assuming that the indexed columns are numeric:
       </para>
 
@@ -2108,7 +2101,7 @@
 SELECT <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=<replaceable>val</replaceable>;
 
 SELECT COUNT(*) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
 
 SELECT <replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> GROUP BY <replaceable>key_part1</replaceable>;
 </programlisting>
@@ -2120,10 +2113,10 @@
 
 <programlisting>
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
 </programlisting>
 
     </section>
@@ -2136,9 +2129,9 @@
         The <literal>range</literal> access method uses a single index
         to retrieve a subset of table rows that are contained within one
         or several index value intervals. It can be used for a
-        single-part or multiple-part index. A detailed description of
-        how intervals are extracted from the <literal>WHERE</literal>
-        clause is given in the following sections.
+        single-part or multiple-part index. The following sections give
+        a detailed description of how intervals are extracted from the
+        <literal>WHERE</literal> clause.
       </para>
 
       <section id="range-access-single-part">
@@ -2237,16 +2230,16 @@
 
 <programlisting>
 SELECT * FROM t1
-    WHERE <replaceable>key_col</replaceable> &gt; 1 
-    AND <replaceable>key_col</replaceable> &lt; 10;
+  WHERE <replaceable>key_col</replaceable> &gt; 1 
+  AND <replaceable>key_col</replaceable> &lt; 10;
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> = 1 
-    OR <replaceable>key_col</replaceable> IN (15,18,20);
+  WHERE <replaceable>key_col</replaceable> = 1 
+  OR <replaceable>key_col</replaceable> IN (15,18,20);
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
-    OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
+  WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
+  OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
 </programlisting>
 
         <para>
@@ -2264,16 +2257,16 @@
         </para>
 
         <para>
-          For example, consider the following statement, where
+          Consider the following statement, where
           <literal>key1</literal> is an indexed column and
           <literal>nonkey</literal> is not indexed:
         </para>
 
 <programlisting>
 SELECT * FROM t1 WHERE
-   (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
-   (key1 &lt; 'bar' AND nonkey = 4) OR
-   (key1 &lt; 'uux' AND key1 &gt; 'z');
+  (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
+  (key1 &lt; 'bar' AND nonkey = 4) OR
+  (key1 &lt; 'uux' AND key1 &gt; 'z');
 </programlisting>
 
         <para>
@@ -2299,7 +2292,7 @@
             <para>
               Remove <literal>nonkey = 4</literal> and <literal>key1
               LIKE '%b'</literal> because they cannot be used for a
-              range scan. The right way to remove them is to replace
+              range scan. The correct way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
               any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
@@ -2345,7 +2338,7 @@
 
             <para>
               Removing unnecessary <literal>TRUE</literal> and
-              <literal>FALSE</literal> constants, we obtain
+              <literal>FALSE</literal> constants, we obtain:
             </para>
 
 <programlisting>
@@ -2367,8 +2360,8 @@
         </orderedlist>
 
         <para>
-          In general (and as demonstrated in the example), the condition
-          used for a range scan is less restrictive than the
+          In general (and as demonstrated by the preceding example), the
+          condition used for a range scan is less restrictive than the
           <literal>WHERE</literal> clause. MySQL performs an additional
           check to filter out rows that satisfy the range condition but
           not the full <literal>WHERE</literal> clause.
@@ -2421,7 +2414,7 @@
         </para>
 
 <programlisting>
-(1, -inf, -inf) &lt;= (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>) &lt; (1, +inf, +inf)
+(1,-inf,-inf) &lt;= (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; (1,+inf,+inf)
 </programlisting>
 
         <para>
@@ -2466,22 +2459,19 @@
               <literal>IS NULL</literal> comparison operators, and the
               conditions cover all index parts. (That is, there are
               <replaceable>N</replaceable> conditions, one for each part
-              of an <replaceable>N</replaceable>-part index.)
-            </para>
-
-            <para>
-              See <xref linkend="range-access-single-part"/>, for the
-              definition of what is considered to be a constant.
-            </para>
-
-            <para>
-              For example, the following is a range condition for a
+              of an <replaceable>N</replaceable>-part index.) For
+              example, the following is a range condition for a
               three-part <literal>HASH</literal> index:
             </para>
 
 <programlisting>
 <replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> IS NULL AND <replaceable>key_part3</replaceable> = 'foo'
 </programlisting>
+
+            <para>
+              For the definition of what is considered to be a constant,
+              see <xref linkend="range-access-single-part"/>.
+            </para>
           </listitem>
 
           <listitem>
@@ -2514,9 +2504,7 @@
             </para>
 
 <programlisting>
-('foo', 10, 10)
-   &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>)
-      &lt; ('foo', +inf, +inf)
+('foo',10,10) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; ('foo',+inf,+inf)
 </programlisting>
 
             <para>
@@ -2541,17 +2529,16 @@
             </para>
 
 <programlisting>
-(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2)
-OR (<replaceable>key_part1</replaceable> &gt; 5)
+(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2) OR (<replaceable>key_part1</replaceable> &gt; 5)
 </programlisting>
 
             <para>
-              The intervals is:
+              The intervals are:
             </para>
 
 <programlisting>
-(1, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>) &lt; (1, 2)
-(5, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>)
+(1,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>) &lt; (1,2)
+(5,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>)
 </programlisting>
 
             <para>
@@ -2579,7 +2566,7 @@
 </programlisting>
 
             <para>
-              But in fact, the condition is converted to this:
+              But, in fact, the condition is converted to this:
             </para>
 
 <programlisting>
@@ -2599,8 +2586,8 @@
         <para>
           <xref linkend="range-access-single-part"/>, describes how
           optimizations are performed to combine or eliminate intervals
-          for range conditions on single-part index. Analogous steps are
-          performed for range conditions on multiple-part keys.
+          for range conditions on a single-part index. Analogous steps
+          are performed for range conditions on multiple-part indexes.
         </para>
 
         <remark role="note">
@@ -2610,13 +2597,10 @@
         </remark>
 
         <remark role="todo">
-          resolve this
+          Resolve this: The text above conflicts with section
+          mysql-indexes.
         </remark>
 
-        <remark role="note">
-          The text above conflicts with section mysql-indexes.
-        </remark>
-
       </section>
 
     </section>
@@ -2636,19 +2620,23 @@
       <para>
         MySQL can perform the same optimization on
         <replaceable>col_name</replaceable> <literal>IS NULL</literal>
-        that it can use with <replaceable>col_name</replaceable>
+        that it can use for <replaceable>col_name</replaceable>
         <literal>=</literal> <replaceable>constant_value</replaceable>.
         For example, MySQL can use indexes and ranges to search for
         <literal>NULL</literal> with <literal>IS NULL</literal>.
       </para>
 
+      <para>
+        Examples:
+      </para>
+
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> IS NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> &lt;=&gt; NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
+  WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
 </programlisting>
 
       <para>
@@ -2689,14 +2677,14 @@
 SELECT * FROM t1, t2 WHERE t1.a=t2.a OR t2.a IS NULL;
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
+  WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
 
 SELECT * FROM t1, t2
-    WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
+  WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
-    OR (t1.a=t2.a AND t2.a IS NULL AND ...);
+  WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
+  OR (t1.a=t2.a AND t2.a IS NULL AND ...);
 </programlisting>
 
       <para>
@@ -2715,8 +2703,8 @@
 
 <programlisting>
 SELECT * FROM t1, t2
-     WHERE (t1.a=t2.a AND t2.a IS NULL)
-     OR (t1.b=t2.b AND t2.b IS NULL);
+  WHERE (t1.a=t2.a AND t2.a IS NULL)
+  OR (t1.b=t2.b AND t2.b IS NULL);
 </programlisting>
 
     </section>
@@ -2740,9 +2728,9 @@
       </para>
 
       <para>
-        Note that because <literal>DISTINCT</literal> may use
-        <literal>GROUP BY</literal>, you should be aware of how MySQL
-        works with columns in <literal>ORDER BY</literal> or
+        Because <literal>DISTINCT</literal> may use <literal>GROUP
+        BY</literal>, you should be aware of how MySQL works with
+        columns in <literal>ORDER BY</literal> or
         <literal>HAVING</literal> clauses that are not part of the
         selected columns. See <xref linkend="group-by-hidden-fields"/>.
       </para>
@@ -2782,8 +2770,8 @@
         <literal>t1</literal> is used before <literal>t2</literal>
         (which you can check with <literal>EXPLAIN</literal>), MySQL
         stops reading from <literal>t2</literal> (for any particular row
-        in <literal>t1</literal>) when the first row in
-        <literal>t2</literal> is found:
+        in <literal>t1</literal>) when it finds the first row in
+        <literal>t2</literal>:
       </para>
 
 <programlisting>
@@ -2806,16 +2794,16 @@
       </indexterm>
 
       <para>
-        An <literal><replaceable>A</replaceable> LEFT JOIN
-        <replaceable>B</replaceable> join_condition</literal> is
-        implemented in MySQL as follows:
+        MySQL implements a <literal><replaceable>A</replaceable> LEFT
+        JOIN <replaceable>B</replaceable> join_condition</literal> as
+        follows:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            Table <literal>B</literal> is set to depend on table
+            Table <replaceable>B</replaceable> is set to depend on table
             <replaceable>A</replaceable> and all tables on which
             <replaceable>A</replaceable> depends.
           </para>
@@ -2882,15 +2870,15 @@
       </itemizedlist>
 
       <para>
-        <literal>RIGHT JOIN</literal> is implemented analogously to
-        <literal>LEFT JOIN</literal>, with the roles of the tables
-        reversed.
+        The implementation of <literal>RIGHT JOIN</literal> is analogous
+        to that of <literal>LEFT JOIN</literal> with the roles of the
+        tables reversed.
       </para>
 
       <para>
         The join optimizer calculates the order in which tables should
         be joined. The table read order forced by <literal>LEFT
-        JOIN</literal> and <literal>STRAIGHT_JOIN</literal> helps the
+        JOIN</literal> or <literal>STRAIGHT_JOIN</literal> helps the
         join optimizer do its work much more quickly, because there are
         fewer table permutations to check. Note that this means that if
         you do a query of the following type, MySQL does a full scan on
@@ -2900,33 +2888,29 @@
 
 <programlisting>
 SELECT *
-    FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        The fix in this case is reverse the order in
+        The fix in this case is reverse the order in which
         <literal>a</literal> and <literal>b</literal> are listed in the
         <literal>FROM</literal> clause:
       </para>
 
 <programlisting>
 SELECT *
-    FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        Starting from 4.0.14, MySQL performs the following <literal>LEFT
-        JOIN</literal> optimization: If the <literal>WHERE</literal>
-        condition is always false for the generated
-        <literal>NULL</literal> row, the <literal>LEFT JOIN</literal> is
-        changed to a normal join.
-      </para>
-
-      <para>
-        For example, the <literal>WHERE</literal> clause would be false
-        in the following query if <literal>t2.column1</literal> were
+        Starting from 4.0.14, for a <literal>LEFT JOIN</literal> , if
+        the <literal>WHERE</literal> condition is always false for the
+        generated <literal>NULL</literal> row, the <literal>LEFT
+        JOIN</literal> is changed to a normal join. For example, the
+        <literal>WHERE</literal> clause would be false in the following
+        query if <literal>t2.column1</literal> were
         <literal>NULL</literal>:
       </para>
 
@@ -2944,9 +2928,9 @@
 
       <para>
         This can be made faster because MySQL can use table
-        <literal>t2</literal> before table <literal>t1</literal> if this
-        would result in a better query plan. To force a specific table
-        order, use <literal>STRAIGHT_JOIN</literal>.
+        <literal>t2</literal> before table <literal>t1</literal> if
+        doing so would result in a better query plan. To force a
+        specific table order, use <literal>STRAIGHT_JOIN</literal>.
       </para>
 
     </section>
@@ -2972,18 +2956,18 @@
 
 <programlisting>
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
     
 SELECT * FROM t1 
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
-    ORDER BY <replaceable>key_part2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
+  ORDER BY <replaceable>key_part2</replaceable>;
     
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
     
 SELECT * FROM t1
-    WHERE <replaceable>key_part1</replaceable>=1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  WHERE <replaceable>key_part1</replaceable>=1 
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
 </programlisting>
 
       <para>
@@ -3182,7 +3166,7 @@
         <listitem>
           <para>
             Read the rows that match the <literal>WHERE</literal>
-            clause, as before.
+            clause.
           </para>
         </listitem>
 
@@ -3225,9 +3209,9 @@
       </para>
 
       <para>
-        If you want to increase <literal>ORDER BY</literal> speed, first
-        see whether you can get MySQL to use indexes rather than an
-        extra sorting phase. If this is not possible, you can try the
+        If you want to increase <literal>ORDER BY</literal> speed, check
+        whether you can get MySQL to use indexes rather than an extra
+        sorting phase. If this is not possible, you can try the
         following strategies:
       </para>
 
@@ -3267,6 +3251,16 @@
       </itemizedlist>
 
       <para>
+        <indexterm>
+          <primary>ORDER BY</primary>
+          <secondary>NULL</secondary>
+        </indexterm>
+
+        <indexterm>
+          <primary>NULL</primary>
+          <secondary>ORDER BY</secondary>
+        </indexterm>
+
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
         <replaceable>col2</replaceable>, &hellip;</literal> queries as
@@ -3316,11 +3310,12 @@
         The most important preconditions for using indexes for
         <literal>GROUP BY</literal> are that all <literal>GROUP
         BY</literal> columns reference attributes from the same index,
-        and the index stores its keys in order (for example, this is a
-        B-Tree index, and not a HASH index). Whether usage of temporary
-        tables can be replaced by index access also depends on which
-        parts of an index are used in a query, the conditions specified
-        for these parts, and the selected aggregate functions.
+        and that the index stores its keys in order (for example, this
+        is a <literal>BTREE</literal> index, and not a
+        <literal>HASH</literal> index). Whether use of temporary tables
+        can be replaced by index access also depends on which parts of
+        an index are used in a query, the conditions specified for these
+        parts, and the selected aggregate functions.
       </para>
 
       <para>
@@ -3594,7 +3589,7 @@
 
 <programlisting>
 SELECT * FROM t1, t2 FORCE INDEX (<replaceable>index_for_column</replaceable>)
-    WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
+  WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
 </programlisting>
         </listitem>
 
@@ -4060,8 +4055,8 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
-    AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
+  WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
+  AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
 </programlisting>
         </listitem>
 
@@ -5087,8 +5082,8 @@
       <para>
         MySQL supports many different storage engines (table types) and
         row formats. For each table, you can decide which storage and
-        indexing method to use. Choosing the right table format for your
-        application may give you a big performance gain. See
+        indexing method to use. Choosing the proper table format for
+        your application may give you a big performance gain. See
         <xref linkend="storage-engines"/>.
       </para>
 
@@ -5365,15 +5360,15 @@
 SELECT * FROM test WHERE last_name='Widenius';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' AND first_name='Michael';
+  WHERE last_name='Widenius' AND first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND (first_name='Michael' OR first_name='Monty');
+  WHERE last_name='Widenius'
+  AND (first_name='Michael' OR first_name='Monty');
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND first_name &gt;='M' AND first_name &lt; 'N';
+  WHERE last_name='Widenius'
+  AND first_name &gt;='M' AND first_name &lt; 'N';
 </programlisting>
 
       <para>
@@ -5385,7 +5380,7 @@
 SELECT * FROM test WHERE first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' OR first_name='Michael';
+  WHERE last_name='Widenius' OR first_name='Michael';
 </programlisting>
 
       <para>
@@ -5485,7 +5480,7 @@
 
 <programlisting>
 SELECT MIN(<replaceable>key_part2</replaceable>),MAX(<replaceable>key_part2</replaceable>)
-    FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
+  FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
 </programlisting>
         </listitem>
 
@@ -5512,7 +5507,7 @@
 
 <programlisting>
 SELECT <replaceable>key_part3</replaceable> FROM <replaceable>tbl_name</replaceable> 
-    WHERE <replaceable>key_part1</replaceable>=1
+  WHERE <replaceable>key_part1</replaceable>=1
 </programlisting>
         </listitem>
 

Modified: trunk/refman-4.1/porting.xml
===================================================================
--- trunk/refman-4.1/porting.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/porting.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -699,7 +699,7 @@
         happens, you should check all your tables with
         <command>myisamchk</command> (see
         <xref linkend="database-administration"/>), and test the queries
-        in the MySQL log files to see if one doesn't work. If you find
+        in the MySQL log files to see whether one fails. If you find
         such a query, try first upgrading to the newest MySQL version.
         If this doesn't help and you can't find anything in the
         <literal>mysql</literal> mail archive, you should report the bug

Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/replication.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -1991,8 +1991,8 @@
 
           <listitem>
             <para>
-              Repeat the procedure later to see if you have better luck
-              next time.
+              Repeat the procedure later to see whether you have better
+              luck next time.
             </para>
           </listitem>
 
@@ -3992,8 +3992,8 @@
       <emphasis role="bold">A</emphasis>: With the currently available
       features, you would have to set up a master and a slave (or
       several slaves), and to write a script that monitors the master to
-      see if it is up. Then instruct your applications and the slaves to
-      change master in case of failure. Some suggestions:
+      check whether it is up. Then instruct your applications and the
+      slaves to change master in case of failure. Some suggestions:
     </para>
 
     <itemizedlist>

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4034,10 +4034,10 @@
             and the client issuing the <literal>INSERT DELAYED</literal>
             statement can then continue. If the table is in use, the
             server holds the rows. When the table is free, the server
-            begins inserting rows, checking periodically to see if there
-            are any new read requests for the table. If there are, the
-            delayed row queue is suspended until the table becomes free
-            again. See <xref linkend="insert-delayed"/>.
+            begins inserting rows, checking periodically to see whether
+            there are any new read requests for the table. If there are,
+            the delayed row queue is suspended until the table becomes
+            free again. See <xref linkend="insert-delayed"/>.
             <literal>DELAYED</literal> was added in MySQL 3.22.5.
           </para>
         </listitem>

Modified: trunk/refman-5.0/connector-odbc.xml
===================================================================
--- trunk/refman-5.0/connector-odbc.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/connector-odbc.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -1451,8 +1451,8 @@
       <para>
         In case while configuring with thread-safe option, and gotten
         into a configure error; then look at the
-        <filename>config.log</filename> and see if it is due to the lack
-        of thread-libraries in the system; and supply one with LIBS
+        <filename>config.log</filename> and see whether it is due to the
+        lack of thread-libraries in the system; and supply one with LIBS
         options i.e.
       </para>
 

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/database-administration.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -6500,10 +6500,10 @@
               This variable applies to NDB. By default it is 0
               (<literal>OFF</literal>): If you execute a query such as
               <literal>SELECT * FROM t WHERE mycol = 42</literal>, where
-              <literal>mycol</literal> is an non-indexed column, the query
-              is executed as a full table scan on every NDB node. Each
-              node sends every row to the MySQL server, which applies
-              the <literal>WHERE</literal> condition. If
+              <literal>mycol</literal> is an non-indexed column, the
+              query is executed as a full table scan on every NDB node.
+              Each node sends every row to the MySQL server, which
+              applies the <literal>WHERE</literal> condition. If
               <literal>engine_condition_pushdown</literal> is set to 1
               (<literal>ON</literal>), the condition is <quote>pushed
               down</quote> to the storage engine and sent to the NDB
@@ -12082,9 +12082,9 @@
             users. The output of <command>mysqladmin
             processlist</command> shows the text of any executing
             queries currently being executed, so any user who is allowed
-            to run that command might be able to see if another user
-            issues an <literal>UPDATE user SET
-            password=PASSWORD('not_secure')</literal> query.
+            to run that command might be able to see whether another
+            user issues a statement such as <literal>UPDATE user SET
+            password=PASSWORD('not_secure')</literal>.
           </para>
 
           <para>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/innodb.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -5263,9 +5263,9 @@
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
-        Before removing them, you might want to examine them to see if
-        they contain useful information about the cause of abnormal
-        shutdowns. The
+        Before removing them, you might want to examine them to see
+        whether they contain useful information about the cause of
+        abnormal shutdowns. The
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
         <literal>innodb_status_file=1</literal> is set.

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/installing.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -11178,8 +11178,8 @@
 
         <para>
           If the server fails to start up correctly, check the error log
-          file to see if you can find out why. Log files are located in
-          the data directory (typically <filename>C:\Program
+          file to see whether you can find out why. Log files are
+          located in the data directory (typically <filename>C:\Program
           Files\MySQL\MySQL Server &current-series;\data</filename> on
           Windows, <filename>/usr/local/mysql/data</filename> for a Unix
           binary distribution, and <filename>/usr/local/var</filename>
@@ -15961,8 +15961,8 @@
             <para>
               Many applications use setuid binaries so that you need to
               specify only a single user. See the documentation provided
-              with the application to see if this is the case for your
-              application.
+              with the application to see whether this is the case for
+              your application.
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4529,9 +4529,10 @@
             <para>
               It is rarely necessary to increase the size of this
               buffer. If there is such a need, then it is a good idea to
-              check if the disks can actually handle the load caused by
-              database update activity. A lack of sufficient disk space
-              cannot be overcome by increasing the size of this buffer.
+              check whether the disks can actually handle the load
+              caused by database update activity. A lack of sufficient
+              disk space cannot be overcome by increasing the size of
+              this buffer.
             </para>
 
             <para>
@@ -9524,11 +9525,10 @@
             evaluation. (That is, function transport is used, rather
             than data transport.) Please note that this feature is
             disabled by default, but it should work in most cases. This
-            feature can be enabled through the use of the
-            <literal>SET engine_condition_pushdown=On;</literal>
-            statement. Alternatively, you can run
-            <command>mysqld</command> with this feature enabled by
-            starting the MySQL server with the
+            feature can be enabled through the use of the <literal>SET
+            engine_condition_pushdown=On;</literal> statement.
+            Alternatively, you can run <command>mysqld</command> with
+            this feature enabled by starting the MySQL server with the
             <option>--engine-condition-pushdown</option> option.
           </para>
 

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/optimization.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -722,7 +722,7 @@
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
         <literal>SELECT</literal> that uses indexes to find rows. You
-        can also use <literal>EXPLAIN</literal> to see whether the
+        can also use <literal>EXPLAIN</literal> to check whether the
         optimizer joins the tables in an optimal order. To force the
         optimizer to use a join order corresponding to the order in
         which the tables are named in the <literal>SELECT</literal>
@@ -930,7 +930,7 @@
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
+  WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
 </programlisting>
             </listitem>
 
@@ -965,7 +965,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1007,7 +1007,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1028,7 +1028,7 @@
 
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable>
-WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
+  WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
 </programlisting>
 
               <para>
@@ -1118,16 +1118,16 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> = 10;
+  WHERE <replaceable>key_column</replaceable> = 10;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
+  WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_column</replaceable> IN (10,20,30);
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
 </programlisting>
             </listitem>
 
@@ -1188,10 +1188,10 @@
             If this column is <literal>NULL</literal>, there are no
             relevant indexes. In this case, you may be able to improve
             the performance of your query by examining the
-            <literal>WHERE</literal> clause to see whether it refers to
-            some column or columns that would be suitable for indexing.
-            If so, create an appropriate index and check the query with
-            <literal>EXPLAIN</literal> again. See
+            <literal>WHERE</literal> clause to check whether it refers
+            to some column or columns that would be suitable for
+            indexing. If so, create an appropriate index and check the
+            query with <literal>EXPLAIN</literal> again. See
             <xref linkend="alter-table"/>.
           </para>
 
@@ -1614,10 +1614,10 @@
         of the <literal>EXPLAIN</literal> output. This should tell you
         roughly how many rows MySQL must examine to execute the query.
         If you restrict queries with the
-        <literal>max_join_size</literal> system variable, this product
-        also is used to determine which multiple-table
-        <literal>SELECT</literal> statements to execute. See
-        <xref linkend="server-parameters"/>.
+        <literal>max_join_size</literal> system variable, this row
+        product also is used to determine which multiple-table
+        <literal>SELECT</literal> statements to execute and which to
+        abort. See <xref linkend="server-parameters"/>.
       </para>
 
       <para>
@@ -1628,7 +1628,7 @@
 
       <para>
         Suppose that you have the <literal>SELECT</literal> statement
-        shown here and you plan to examine it using
+        shown here and that you plan to examine it using
         <literal>EXPLAIN</literal>:
       </para>
 
@@ -1770,9 +1770,9 @@
         Cartesian product of all the tables; that is, every combination
         of rows. This takes quite a long time, because the product of
         the number of rows in each table must be examined. For the case
-        at hand, this product is <literal>74 &times; 2135 &times; 74
-        &times; 3872 = 45,268,558,720</literal> rows. If the tables were
-        bigger, you can only imagine how long it would take.
+        at hand, this product is 74 &times; 2135 &times; 74 &times; 3872
+        = 45,268,558,720 rows. If the tables were bigger, you can only
+        imagine how long it would take.
       </para>
 
       <para>
@@ -1797,7 +1797,7 @@
 </programlisting>
 
       <para>
-        <literal>tt.ActualPC</literal> and
+        Now <literal>tt.ActualPC</literal> and
         <literal>et.EMPLOYID</literal> are both
         <literal>VARCHAR(15)</literal>. Executing the
         <literal>EXPLAIN</literal> statement again produces this result:
@@ -1818,7 +1818,7 @@
       <para>
         This is not perfect, but is much better: The product of the
         <literal>rows</literal> values is less by a factor of 74. This
-        version is executed in a couple of seconds.
+        version executes in a couple of seconds.
       </para>
 
       <para>
@@ -1834,7 +1834,8 @@
 </programlisting>
 
       <para>
-        <literal>EXPLAIN</literal> produces the output shown here:
+        After that modification, <literal>EXPLAIN</literal> produces the
+        output shown here:
       </para>
 
 <programlisting>
@@ -1848,13 +1849,10 @@
 </programlisting>
 
       <para>
-        This is almost as good as it can get.
-      </para>
-
-      <para>
-        The remaining problem is that, by default, MySQL assumes that
-        values in the <literal>tt.ActualPC</literal> column are evenly
-        distributed, and that is not the case for the
+        At this point, the query is optimized almost as well as
+        possible. The remaining problem is that, by default, MySQL
+        assumes that values in the <literal>tt.ActualPC</literal> column
+        are evenly distributed, and that is not the case for the
         <literal>tt</literal> table. Fortunately, it is easy to tell
         MySQL to analyze the key distribution:
       </para>
@@ -1863,18 +1861,9 @@
 mysql&gt; <userinput>ANALYZE TABLE tt;</userinput>
 </programlisting>
 
-<!--
-    
-<programlisting>
-shell&gt; <userinput>myisamchk -analyze PATH_TO_MYSQL_DATABASE/tt</userinput>
-shell&gt; <userinput>mysqladmin refresh</userinput>
-</programlisting>
-
--->
-
       <para>
-        The join is perfect, and <literal>EXPLAIN</literal> produces
-        this result:
+        With the additional index information, the join is perfect and
+        <literal>EXPLAIN</literal> produces this result:
       </para>
 
 <programlisting>
@@ -1891,8 +1880,10 @@
         Note that the <literal>rows</literal> column in the output from
         <literal>EXPLAIN</literal> is an educated guess from the MySQL
         join optimizer. You should check whether the numbers are even
-        close to the truth. If not, you may get better performance by
-        using <literal>STRAIGHT_JOIN</literal> in your
+        close to the truth by comparing the <literal>rows</literal>
+        product with the actual number of rows that the query returns.
+        If the numbers are quite different, you might get better
+        performance by using <literal>STRAIGHT_JOIN</literal> in your
         <literal>SELECT</literal> statement and trying to list the
         tables in a different order in the <literal>FROM</literal>
         clause.
@@ -1920,11 +1911,11 @@
       </indexterm>
 
       <para>
-        In most cases, you can estimate the performance by counting disk
-        seeks. For small tables, you can usually find a row in one disk
-        seek (because the index is probably cached). For bigger tables,
-        you can estimate that, using B-tree indexes, you need this many
-        seeks to find a row:
+        In most cases, you can estimate query performance by counting
+        disk seeks. For small tables, you can usually find a row in one
+        disk seek (because the index is probably cached). For bigger
+        tables, you can estimate that, using B-tree indexes, you need
+        this many seeks to find a row:
         <literal>log(<replaceable>row_count</replaceable>) /
         log(<replaceable>index_block_length</replaceable> / 3 &times; 2
         / (<replaceable>index_length</replaceable> +
@@ -1932,9 +1923,10 @@
       </para>
 
       <para>
-        In MySQL, an index block is usually 1024 bytes and the data
-        pointer is usually 4 bytes. For a 500,000-row table with an
-        index length of 3 bytes (medium integer), the formula indicates
+        In MySQL, an index block is usually 1,024 bytes and the data
+        pointer is usually four bytes. For a 500,000-row table with an
+        index length of three bytes (the size of
+        <literal>MEDIUMINT</literal>), the formula indicates
         <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
         <literal>4</literal> seeks.
       </para>
@@ -1948,7 +1940,7 @@
 
       <para>
         For writes, however, you need four seek requests to find where
-        to place the new index and normally two seeks to update the
+        to place a new index value and normally two seeks to update the
         index and write the row.
       </para>
 
@@ -1989,7 +1981,7 @@
         different tables should usually be done with indexes. You can
         use the <literal>EXPLAIN</literal> statement to determine which
         indexes are used for a <literal>SELECT</literal>. See
-        <xref linkend="mysql-indexes"/>, and <xref linkend="explain"/>.
+        <xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
       </para>
 
       <para>
@@ -2021,11 +2013,11 @@
           <para>
             To sort an index and data according to an index, use
             <command>myisamchk --sort-index --sort-records=1</command>
-            (if you want to sort on index 1). This is a good way to make
-            queries faster if you have a unique index from which you
-            want to read all rows in order according to the index. Note
-            that the first time you sort a large table this way, it may
-            take a long time.
+            (assuming that you want to sort on index 1). This is a good
+            way to make queries faster if you have a unique index from
+            which you want to read all rows in order according to the
+            index. Note that the first time you sort a large table this
+            way, it may take a long time.
           </para>
         </listitem>
 
@@ -2055,13 +2047,13 @@
       </para>
 
       <para>
-        Note that work on the MySQL optimizer is ongoing, so this
-        section is incomplete. MySQL performs a great many
-        optimizations, not all of which are documented here.
+        Work on the MySQL optimizer is ongoing, so this section is
+        incomplete. MySQL performs a great many optimizations, not all
+        of which are documented here.
       </para>
 
       <para>
-        Some of the optimizations performed by MySQL are listed here:
+        Some of the optimizations performed by MySQL follow:
       </para>
 
       <itemizedlist>
@@ -2130,8 +2122,9 @@
           <para>
             <literal>HAVING</literal> is merged with
             <literal>WHERE</literal> if you do not use <literal>GROUP
-            BY</literal> or group functions (<literal>COUNT()</literal>,
-            <literal>MIN()</literal>, and so on).
+            BY</literal> or aggregate functions
+            (<literal>COUNT()</literal>, <literal>MIN()</literal>, and
+            so on).
           </para>
         </listitem>
 
@@ -2186,7 +2179,7 @@
 <programlisting>
 SELECT * FROM t WHERE <replaceable>primary_key</replaceable>=1;
 SELECT * FROM t1,t2
-    WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
+  WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
 </programlisting>
         </listitem>
 
@@ -2212,8 +2205,8 @@
 
         <listitem>
           <para>
-            If you use <literal>SQL_SMALL_RESULT</literal>, MySQL uses
-            an in-memory temporary table.
+            If you use the <literal>SQL_SMALL_RESULT</literal> option,
+            MySQL uses an in-memory temporary table.
           </para>
         </listitem>
 
@@ -2222,11 +2215,11 @@
             Each table index is queried, and the best index is used
             unless the optimizer believes that it is more efficient to
             use a table scan. At one time, a scan was used based on
-            whether the best index spanned more than 30% of the table.
-            The optimizer is more complex and bases its estimate on
-            additional factors such as table size, number of rows, and
-            I/O block size, so a fixed percentage no longer determines
-            the choice between using an index or a scan.
+            whether the best index spanned more than 30% of the table,
+            but a fixed percentage no longer determines the choice
+            between using an index or a scan. The optimizer now is more
+            complex and bases its estimate on additional factors such as
+            table size, number of rows, and I/O block size.
           </para>
         </listitem>
 
@@ -2258,17 +2251,17 @@
 SELECT MIN(<replaceable>key_part1</replaceable>),MAX(<replaceable>key_part1</replaceable>) FROM <replaceable>tbl_name</replaceable>;
 
 SELECT MAX(<replaceable>key_part2</replaceable>) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
 </programlisting>
 
       <para>
-        The following queries are resolved using only the index tree,
+        MySQL resolves the following queries using only the index tree,
         assuming that the indexed columns are numeric:
       </para>
 
@@ -2276,7 +2269,7 @@
 SELECT <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=<replaceable>val</replaceable>;
 
 SELECT COUNT(*) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
 
 SELECT <replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> GROUP BY <replaceable>key_part1</replaceable>;
 </programlisting>
@@ -2288,10 +2281,10 @@
 
 <programlisting>
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
 </programlisting>
 
     </section>
@@ -2304,9 +2297,9 @@
         The <literal>range</literal> access method uses a single index
         to retrieve a subset of table rows that are contained within one
         or several index value intervals. It can be used for a
-        single-part or multiple-part index. A detailed description of
-        how intervals are extracted from the <literal>WHERE</literal>
-        clause is given in the following sections.
+        single-part or multiple-part index. The following sections give
+        a detailed description of how intervals are extracted from the
+        <literal>WHERE</literal> clause.
       </para>
 
       <section id="range-access-single-part">
@@ -2405,16 +2398,16 @@
 
 <programlisting>
 SELECT * FROM t1
-    WHERE <replaceable>key_col</replaceable> &gt; 1 
-    AND <replaceable>key_col</replaceable> &lt; 10;
+  WHERE <replaceable>key_col</replaceable> &gt; 1 
+  AND <replaceable>key_col</replaceable> &lt; 10;
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> = 1 
-    OR <replaceable>key_col</replaceable> IN (15,18,20);
+  WHERE <replaceable>key_col</replaceable> = 1 
+  OR <replaceable>key_col</replaceable> IN (15,18,20);
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
-    OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
+  WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
+  OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
 </programlisting>
 
         <para>
@@ -2432,16 +2425,16 @@
         </para>
 
         <para>
-          For example, consider the following statement, where
+          Consider the following statement, where
           <literal>key1</literal> is an indexed column and
           <literal>nonkey</literal> is not indexed:
         </para>
 
 <programlisting>
 SELECT * FROM t1 WHERE
-   (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
-   (key1 &lt; 'bar' AND nonkey = 4) OR
-   (key1 &lt; 'uux' AND key1 &gt; 'z');
+  (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
+  (key1 &lt; 'bar' AND nonkey = 4) OR
+  (key1 &lt; 'uux' AND key1 &gt; 'z');
 </programlisting>
 
         <para>
@@ -2467,7 +2460,7 @@
             <para>
               Remove <literal>nonkey = 4</literal> and <literal>key1
               LIKE '%b'</literal> because they cannot be used for a
-              range scan. The right way to remove them is to replace
+              range scan. The correct way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
               any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
@@ -2513,7 +2506,7 @@
 
             <para>
               Removing unnecessary <literal>TRUE</literal> and
-              <literal>FALSE</literal> constants, we obtain
+              <literal>FALSE</literal> constants, we obtain:
             </para>
 
 <programlisting>
@@ -2535,8 +2528,8 @@
         </orderedlist>
 
         <para>
-          In general (and as demonstrated in the example), the condition
-          used for a range scan is less restrictive than the
+          In general (and as demonstrated by the preceding example), the
+          condition used for a range scan is less restrictive than the
           <literal>WHERE</literal> clause. MySQL performs an additional
           check to filter out rows that satisfy the range condition but
           not the full <literal>WHERE</literal> clause.
@@ -2589,7 +2582,7 @@
         </para>
 
 <programlisting>
-(1, -inf, -inf) &lt;= (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>) &lt; (1, +inf, +inf)
+(1,-inf,-inf) &lt;= (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; (1,+inf,+inf)
 </programlisting>
 
         <para>
@@ -2634,22 +2627,19 @@
               <literal>IS NULL</literal> comparison operators, and the
               conditions cover all index parts. (That is, there are
               <replaceable>N</replaceable> conditions, one for each part
-              of an <replaceable>N</replaceable>-part index.)
-            </para>
-
-            <para>
-              See <xref linkend="range-access-single-part"/>, for the
-              definition of what is considered to be a constant.
-            </para>
-
-            <para>
-              For example, the following is a range condition for a
+              of an <replaceable>N</replaceable>-part index.) For
+              example, the following is a range condition for a
               three-part <literal>HASH</literal> index:
             </para>
 
 <programlisting>
 <replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> IS NULL AND <replaceable>key_part3</replaceable> = 'foo'
 </programlisting>
+
+            <para>
+              For the definition of what is considered to be a constant,
+              see <xref linkend="range-access-single-part"/>.
+            </para>
           </listitem>
 
           <listitem>
@@ -2682,9 +2672,7 @@
             </para>
 
 <programlisting>
-('foo', 10, 10)
-   &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>)
-      &lt; ('foo', +inf, +inf)
+('foo',10,10) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; ('foo',+inf,+inf)
 </programlisting>
 
             <para>
@@ -2709,17 +2697,16 @@
             </para>
 
 <programlisting>
-(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2)
-OR (<replaceable>key_part1</replaceable> &gt; 5)
+(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2) OR (<replaceable>key_part1</replaceable> &gt; 5)
 </programlisting>
 
             <para>
-              The intervals is:
+              The intervals are:
             </para>
 
 <programlisting>
-(1, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>) &lt; (1, 2)
-(5, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>)
+(1,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>) &lt; (1,2)
+(5,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>)
 </programlisting>
 
             <para>
@@ -2747,7 +2734,7 @@
 </programlisting>
 
             <para>
-              But in fact, the condition is converted to this:
+              But, in fact, the condition is converted to this:
             </para>
 
 <programlisting>
@@ -2767,8 +2754,8 @@
         <para>
           <xref linkend="range-access-single-part"/>, describes how
           optimizations are performed to combine or eliminate intervals
-          for range conditions on single-part index. Analogous steps are
-          performed for range conditions on multiple-part keys.
+          for range conditions on a single-part index. Analogous steps
+          are performed for range conditions on multiple-part indexes.
         </para>
 
 <!--  
@@ -2782,13 +2769,10 @@
 -->
 
         <remark role="todo">
-          resolve this
+          Resolve this: The text above conflicts with section
+          mysql-indexes.
         </remark>
 
-        <remark role="note">
-          The text above conflicts with section mysql-indexes.
-        </remark>
-
       </section>
 
     </section>
@@ -2827,11 +2811,12 @@
       </para>
 
       <para>
-        In <literal>EXPLAIN</literal> output, this method appears as
-        <literal>index_merge</literal> in the <literal>type</literal>
-        column. In this case, the <literal>key</literal> column contains
-        a list of indexes used, and <literal>key_len</literal> contains
-        a list of the longest key parts for those indexes.
+        In <literal>EXPLAIN</literal> output, the Index Merge method
+        appears as <literal>index_merge</literal> in the
+        <literal>type</literal> column. In this case, the
+        <literal>key</literal> column contains a list of indexes used,
+        and <literal>key_len</literal> contains a list of the longest
+        key parts for those indexes.
       </para>
 
       <para>
@@ -2842,15 +2827,15 @@
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE (<replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20) AND <replaceable>non_key_part</replaceable>=30;
+  WHERE (<replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20) AND <replaceable>non_key_part</replaceable>=30;
 
 SELECT * FROM t1, t2
-    WHERE (t1.<replaceable>key1</replaceable> IN (1,2) OR t1.<replaceable>key2</replaceable> LIKE '<replaceable>value</replaceable>%')
-    AND t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable>;
+  WHERE (t1.<replaceable>key1</replaceable> IN (1,2) OR t1.<replaceable>key2</replaceable> LIKE '<replaceable>value</replaceable>%')
+  AND t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable>;
 
 SELECT * FROM t1, t2
-    WHERE t1.<replaceable>key1</replaceable>=1
-    AND (t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable> OR t2.<replaceable>key2</replaceable>=t1.<replaceable>some_col2</replaceable>);
+  WHERE t1.<replaceable>key1</replaceable>=1
+  AND (t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable> OR t2.<replaceable>key2</replaceable>=t1.<replaceable>some_col2</replaceable>);
 </programlisting>
 
       <para>
@@ -2863,19 +2848,19 @@
 
         <listitem>
           <para>
-            intersection
+            <literal>Using intersect(&hellip;)</literal>
           </para>
         </listitem>
 
         <listitem>
           <para>
-            union
+            <literal>Using union(&hellip;)</literal>
           </para>
         </listitem>
 
         <listitem>
           <para>
-            sort-union
+            <literal>Using sort_union(&hellip;)</literal>
           </para>
         </listitem>
 
@@ -2906,7 +2891,7 @@
             For this query, two plans are possible:
           </para>
 
-          <orderedlist>
+          <itemizedlist>
 
             <listitem>
               <para>
@@ -2922,23 +2907,22 @@
               </para>
             </listitem>
 
-          </orderedlist>
+          </itemizedlist>
 
           <para>
-            However, the optimizer only considers the second plan. If
+            However, the optimizer considers only the second plan. If
             that is not what you want, you can make the optimizer
-            consider <literal>index_merge</literal> by using
-            <literal>IGNORE INDEX</literal> or <literal>FORCE
-            INDEX</literal>. The following queries are executed using
-            Index Merge:
+            consider Index Merge by using <literal>IGNORE
+            INDEX</literal> or <literal>FORCE INDEX</literal>. The
+            following queries are executed using Index Merge:
           </para>
 
 <programlisting>
 SELECT * FROM t1 FORCE INDEX(goodkey1,goodkey2)
-WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
+  WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
 
 SELECT * FROM t1 IGNORE INDEX(badkey)
-WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
+  WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
 </programlisting>
         </listitem>
 
@@ -2959,9 +2943,9 @@
       </itemizedlist>
 
       <para>
-        The choice between different possible variants of the
-        <literal>index_merge</literal> access method and other access
-        methods is based on cost estimates of various available options.
+        The choice between different possible variants of the Index
+        Merge access method and other access methods is based on cost
+        estimates of various available options.
       </para>
 
       <section id="index-merge-intersection">
@@ -3000,14 +2984,14 @@
         </itemizedlist>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
 SELECT * FROM <replaceable>innodb_table</replaceable> WHERE <replaceable>primary_key</replaceable> &lt; 10 AND <replaceable>key_col1</replaceable>=20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE (<replaceable>key1_part1</replaceable>=1 AND <replaceable>key1_part2</replaceable>=2) AND <replaceable>key2</replaceable>=2;
+  WHERE (<replaceable>key1_part1</replaceable>=1 AND <replaceable>key1_part2</replaceable>=2) AND <replaceable>key2</replaceable>=2;
 </programlisting>
 
         <para>
@@ -3018,10 +3002,10 @@
 
         <para>
           If all columns used in the query are covered by the used
-          indexes, full table rows are not retrieved and
+          indexes, full table rows are not retrieved
           (<literal>EXPLAIN</literal> output contains <literal>Using
           index</literal> in <literal>Extra</literal> field in this
-          case). Here is an example of such query:
+          case). Here is an example of such a query:
         </para>
 
 <programlisting>
@@ -3088,7 +3072,7 @@
         </itemizedlist>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
@@ -3112,14 +3096,14 @@
         </para>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col1</replaceable> &lt; 10 OR <replaceable>key_col2</replaceable> &lt; 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-     WHERE (<replaceable>key_col1</replaceable> &gt; 10 OR <replaceable>key_col2</replaceable> = 20) AND <replaceable>nonkey_col</replaceable>=30;
+  WHERE (<replaceable>key_col1</replaceable> &gt; 10 OR <replaceable>key_col2</replaceable> = 20) AND <replaceable>nonkey_col</replaceable>=30;
 </programlisting>
 
         <para>
@@ -3147,19 +3131,23 @@
       <para>
         MySQL can perform the same optimization on
         <replaceable>col_name</replaceable> <literal>IS NULL</literal>
-        that it can use with <replaceable>col_name</replaceable>
+        that it can use for <replaceable>col_name</replaceable>
         <literal>=</literal> <replaceable>constant_value</replaceable>.
         For example, MySQL can use indexes and ranges to search for
         <literal>NULL</literal> with <literal>IS NULL</literal>.
       </para>
 
+      <para>
+        Examples:
+      </para>
+
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> IS NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> &lt;=&gt; NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
+  WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
 </programlisting>
 
       <para>
@@ -3200,14 +3188,14 @@
 SELECT * FROM t1, t2 WHERE t1.a=t2.a OR t2.a IS NULL;
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
+  WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
 
 SELECT * FROM t1, t2
-    WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
+  WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
-    OR (t1.a=t2.a AND t2.a IS NULL AND ...);
+  WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
+  OR (t1.a=t2.a AND t2.a IS NULL AND ...);
 </programlisting>
 
       <para>
@@ -3226,8 +3214,8 @@
 
 <programlisting>
 SELECT * FROM t1, t2
-     WHERE (t1.a=t2.a AND t2.a IS NULL)
-     OR (t1.b=t2.b AND t2.b IS NULL);
+  WHERE (t1.a=t2.a AND t2.a IS NULL)
+  OR (t1.b=t2.b AND t2.b IS NULL);
 </programlisting>
 
     </section>
@@ -3251,9 +3239,9 @@
       </para>
 
       <para>
-        Note that because <literal>DISTINCT</literal> may use
-        <literal>GROUP BY</literal>, you should be aware of how MySQL
-        works with columns in <literal>ORDER BY</literal> or
+        Because <literal>DISTINCT</literal> may use <literal>GROUP
+        BY</literal>, you should be aware of how MySQL works with
+        columns in <literal>ORDER BY</literal> or
         <literal>HAVING</literal> clauses that are not part of the
         selected columns. See <xref linkend="group-by-hidden-fields"/>.
       </para>
@@ -3293,8 +3281,8 @@
         <literal>t1</literal> is used before <literal>t2</literal>
         (which you can check with <literal>EXPLAIN</literal>), MySQL
         stops reading from <literal>t2</literal> (for any particular row
-        in <literal>t1</literal>) when the first row in
-        <literal>t2</literal> is found:
+        in <literal>t1</literal>) when it finds the first row in
+        <literal>t2</literal>:
       </para>
 
 <programlisting>
@@ -3317,16 +3305,16 @@
       </indexterm>
 
       <para>
-        An <literal><replaceable>A</replaceable> LEFT JOIN
-        <replaceable>B</replaceable> join_condition</literal> is
-        implemented in MySQL as follows:
+        MySQL implements an <literal><replaceable>A</replaceable> LEFT
+        JOIN <replaceable>B</replaceable> join_condition</literal> as
+        follows:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            Table <literal>B</literal> is set to depend on table
+            Table <replaceable>B</replaceable> is set to depend on table
             <replaceable>A</replaceable> and all tables on which
             <replaceable>A</replaceable> depends.
           </para>
@@ -3393,15 +3381,15 @@
       </itemizedlist>
 
       <para>
-        <literal>RIGHT JOIN</literal> is implemented analogously to
-        <literal>LEFT JOIN</literal>, with the roles of the tables
-        reversed.
+        The implementation of <literal>RIGHT JOIN</literal> is analogous
+        to that of <literal>LEFT JOIN</literal> with the roles of the
+        tables reversed.
       </para>
 
       <para>
         The join optimizer calculates the order in which tables should
         be joined. The table read order forced by <literal>LEFT
-        JOIN</literal> and <literal>STRAIGHT_JOIN</literal> helps the
+        JOIN</literal> or <literal>STRAIGHT_JOIN</literal> helps the
         join optimizer do its work much more quickly, because there are
         fewer table permutations to check. Note that this means that if
         you do a query of the following type, MySQL does a full scan on
@@ -3411,32 +3399,29 @@
 
 <programlisting>
 SELECT *
-    FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        The fix in this case is reverse the order in
+        The fix in this case is reverse the order in which
         <literal>a</literal> and <literal>b</literal> are listed in the
         <literal>FROM</literal> clause:
       </para>
 
 <programlisting>
 SELECT *
-    FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        MySQL performs the following <literal>LEFT JOIN</literal>
-        optimization: If the <literal>WHERE</literal> condition is
-        always false for the generated <literal>NULL</literal> row, the
-        <literal>LEFT JOIN</literal> is changed to a normal join.
-      </para>
-
-      <para>
-        For example, the <literal>WHERE</literal> clause would be false
-        in the following query if <literal>t2.column1</literal> were
+        For a <literal>LEFT JOIN</literal>, if the
+        <literal>WHERE</literal> condition is always false for the
+        generated <literal>NULL</literal> row, the <literal>LEFT
+        JOIN</literal> is changed to a normal join. For example, the
+        <literal>WHERE</literal> clause would be false in the following
+        query if <literal>t2.column1</literal> were
         <literal>NULL</literal>:
       </para>
 
@@ -3454,9 +3439,9 @@
 
       <para>
         This can be made faster because MySQL can use table
-        <literal>t2</literal> before table <literal>t1</literal> if this
-        would result in a better query plan. To force a specific table
-        order, use <literal>STRAIGHT_JOIN</literal>.
+        <literal>t2</literal> before table <literal>t1</literal> if
+        doing so would result in a better query plan. To force a
+        specific table order, use <literal>STRAIGHT_JOIN</literal>.
       </para>
 
     </section>
@@ -3475,22 +3460,19 @@
         The syntax of <replaceable>table_factor</replaceable> is
         extended in comparison with the SQL Standard. The latter accepts
         only <replaceable>table_reference</replaceable>, not a list of
-        them inside a pair of parentheses.
+        them inside a pair of parentheses. This is a conservative
+        extension if we consider each comma in a list of
+        <replaceable>table_reference</replaceable> items as equivalent
+        to an inner join. For example:
       </para>
 
-      <para>
-        This is a conservative extension if we consider each comma in a
-        list of <replaceable>table_reference</replaceable> items as
-        equivalent to an inner join. For example:
-      </para>
-
 <programlisting>
 SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                  ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
 </programlisting>
 
       <para>
-        is equivalent to :
+        is equivalent to:
       </para>
 
 <programlisting>
@@ -3501,7 +3483,7 @@
       <para>
         In MySQL, <literal>CROSS JOIN</literal> is a syntactic
         equivalent to <literal>INNER JOIN</literal> (they can replace
-        each other. In standard SQL, they are not equivalent.
+        each other). In standard SQL, they are not equivalent.
         <literal>INNER JOIN</literal> is used with an
         <literal>ON</literal> clause; <literal>CROSS JOIN</literal> is
         used otherwise.
@@ -3618,11 +3600,8 @@
 </programlisting>
 
       <para>
-        For the given table states, the first expression returns rows
-        <literal>{1,1,101,101}</literal>,
-        <literal>{2,NULL,NULL,NULL}</literal>, whereas the second
-        expression returns rows <literal>{1,1,101,101}</literal>,
-        <literal>{2,NULL,NULL,101}</literal>:
+        For the given table states, the two expressions return different
+        sets of rows:
       </para>
 
 <programlisting>
@@ -3654,7 +3633,7 @@
       <para>
         More exactly, we cannot ignore parentheses in the right operand
         of the left outer join operation and in the left operand of a
-        right join operation. In other words, we can't ignore
+        right join operation. In other words, we cannot ignore
         parentheses for the inner table expressions of outer join
         operations. Parentheses for the other operand (operand for the
         outer table) can be ignored.
@@ -3669,7 +3648,7 @@
 </programlisting>
 
       <para>
-        is equivalent to the expression
+        is equivalent to this expression:
       </para>
 
 <programlisting>
@@ -3685,8 +3664,8 @@
       <para>
         Whenever the order of execution of the join operations in a join
         expression (<replaceable>join_table</replaceable>) is not from
-        left to right, we talk about nested joins. Thus, the following
-        queries:
+        left to right, we talk about nested joins. Consider the
+        following queries:
       </para>
 
 <programlisting>
@@ -3698,7 +3677,7 @@
 </programlisting>
 
       <para>
-        the join tables:
+        Those queries are considered to contain these nested joins:
       </para>
 
 <programlisting>
@@ -3707,15 +3686,15 @@
 </programlisting>
 
       <para>
-        are considered as nested. The nested join is formed in the first
-        query with a left join operation, whereas in the second query it
-        is formed with an inner join operation.
+        The nested join is formed in the first query with a left join
+        operation, whereas in the second query it is formed with an
+        inner join operation.
       </para>
 
       <para>
         In the first query, the parentheses can be omitted: The
         grammatical structure of the join expression will dictate the
-        same order of execution for join operations. Yet for the second
+        same order of execution for join operations. For the second
         query, the parentheses cannot be omitted, although the join
         expression here can be interpreted unambiguously without them.
         (In our extended syntax the parentheses in <literal>(t2,
@@ -3737,38 +3716,27 @@
           <para>
             For join expressions involving only inner joins (and not
             outer joins), parentheses can be removed. You can remove
-            parentheses and evaluate left to right (or in fact, you can
+            parentheses and evaluate left to right (or, in fact, you can
             evaluate the tables in any order).
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The same is not true, in general, for outer joins. Removal
-            of parentheses may change the result.
+            The same is not true, in general, for outer joins or for
+            outer joins mixed with inner joins. Removal of parentheses
+            may change the result.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            The same also is not true, in general, for outer joins mixed
-            with inner joins. Removal of parentheses may change the
-            result.
-          </para>
-        </listitem>
-
       </itemizedlist>
 
       <para>
         Queries with nested outer joins are executed in the same
         pipeline manner as queries with inner joins. More exactly, a
-        variation of the nested-loop join algorithm is exploited. Let's
-        recall by what algorithmic schema the nested-loop join executes
-        a query.
-      </para>
-
-      <para>
-        Suppose that we have a join query over 3 tables
+        variation of the nested-loop join algorithm is exploited. Recall
+        by what algorithmic schema the nested-loop join executes a
+        query. Suppose that we have a join query over 3 tables
         <literal>T1,T2,T3</literal> of the form:
       </para>
 
@@ -3787,7 +3755,7 @@
 
       <para>
         The nested-loop join algorithm would execute this query in the
-        following way:
+        following manner:
       </para>
 
 <programlisting>
@@ -3828,7 +3796,7 @@
 </programlisting>
 
       <para>
-        For this query we modify the nested-loop pattern to get:
+        For this query, we modify the nested-loop pattern to get:
       </para>
 
 <programlisting>
@@ -3936,7 +3904,7 @@
 </programlisting>
 
       <para>
-        and
+        and:
       </para>
 
 <programlisting>
@@ -3969,7 +3937,7 @@
       </para>
 
       <para>
-        When discussing about nested-loop algorithm for inner joins, we
+        When discussing the nested-loop algorithm for inner joins, we
         omitted some details whose impact on the performance of query
         execution may be huge. We did not mention so-called
         <quote>pushed-down</quote> conditions. Suppose that our
@@ -4006,14 +3974,14 @@
         be evaluated. If <literal>C1(T1)</literal> is a very restrictive
         condition, this condition pushdown may greatly reduce the number
         of rows from table <literal>T1</literal> passed to the inner
-        loops. As a result, the execution time for query may improve
+        loops. As a result, the execution time for the query may improve
         immensely.
       </para>
 
       <para>
         For a query with outer joins, the <literal>WHERE</literal>
-        condition is to be checked only after it has been found out that
-        the current row from the outer table has a match in the inner
+        condition is to be checked only after it has been found that the
+        current row from the outer table has a match in the inner
         tables. Thus, the optimization with pushing condition out of the
         inner nested loops cannot be applied directly to queries with
         outer joins. Here we have to introduce conditional pushed-down
@@ -4022,7 +3990,7 @@
       </para>
 
       <para>
-        For our example with outer joins with
+        For our example with outer joins with:
       </para>
 
 <programlisting>
@@ -4065,7 +4033,7 @@
         In general, pushed-down predicates can be extracted from join
         conditions such as <literal>P1(T1,T2)</literal> and
         <literal>P(T2,T3)</literal>. In this case, a pushed-down
-        predicates are guarded also by a flag that prevents checking the
+        predicate is guarded also by a flag that prevents checking the
         predicate for the <literal>NULL</literal>-complemented row
         generated by the corresponding outer join operation.
       </para>
@@ -4336,7 +4304,7 @@
 
       <para>
         When trying to convert an embedded outer join operation in a
-        query, we have to take into account the join condition for the
+        query, we must take into account the join condition for the
         embedding outer join together with the <literal>WHERE</literal>
         condition. In the query:
       </para>
@@ -4393,18 +4361,18 @@
 
 <programlisting>
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
     
 SELECT * FROM t1 
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
-    ORDER BY <replaceable>key_part2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
+  ORDER BY <replaceable>key_part2</replaceable>;
     
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
     
 SELECT * FROM t1
-    WHERE <replaceable>key_part1</replaceable>=1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  WHERE <replaceable>key_part1</replaceable>=1 
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
 </programlisting>
 
       <para>
@@ -4518,7 +4486,7 @@
         <listitem>
           <para>
             Read the rows that match the <literal>WHERE</literal>
-            clause, as before.
+            clause.
           </para>
         </listitem>
 
@@ -4561,9 +4529,9 @@
       </para>
 
       <para>
-        If you want to increase <literal>ORDER BY</literal> speed, first
-        see whether you can get MySQL to use indexes rather than an
-        extra sorting phase. If this is not possible, you can try the
+        If you want to increase <literal>ORDER BY</literal> speed, check
+        whether you can get MySQL to use indexes rather than an extra
+        sorting phase. If this is not possible, you can try the
         following strategies:
       </para>
 
@@ -4602,6 +4570,16 @@
       </itemizedlist>
 
       <para>
+        <indexterm>
+          <primary>ORDER BY</primary>
+          <secondary>NULL</secondary>
+        </indexterm>
+
+        <indexterm>
+          <primary>NULL</primary>
+          <secondary>ORDER BY</secondary>
+        </indexterm>
+
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
         <replaceable>col2</replaceable>, &hellip;</literal> queries as
@@ -4651,11 +4629,12 @@
         The most important preconditions for using indexes for
         <literal>GROUP BY</literal> are that all <literal>GROUP
         BY</literal> columns reference attributes from the same index,
-        and the index stores its keys in order (for example, this is a
-        B-Tree index, and not a HASH index). Whether usage of temporary
-        tables can be replaced by index access also depends on which
-        parts of an index are used in a query, the conditions specified
-        for these parts, and the selected aggregate functions.
+        and that the index stores its keys in order (for example, this
+        is a <literal>BTREE</literal> index and not a
+        <literal>HASH</literal> index). Whether use of temporary tables
+        can be replaced by index access also depends on which parts of
+        an index are used in a query, the conditions specified for these
+        parts, and the selected aggregate functions.
       </para>
 
       <para>
@@ -4671,10 +4650,11 @@
         <title>&title-loose-index-scan;</title>
 
         <para>
-          The most efficient way is when the index is used to directly
-          retrieve the group fields. With this access method, MySQL uses
-          the property of some index types (for example, B-Trees) that
-          the keys are ordered. This property enables use of lookup
+          The most efficient way to process <literal>GROUP BY</literal>
+          is when the index is used to directly retrieve the group
+          fields. With this access method, MySQL uses the property of
+          some index types that the keys are ordered (for example,
+          <literal>BTREE</literal>). This property enables use of lookup
           groups in an index without having to consider all keys in the
           index that satisfy all <literal>WHERE</literal> conditions.
           This access method considers only a fraction of the keys in an
@@ -4683,8 +4663,8 @@
           clause, a loose index scan reads as many keys as the number of
           groups, which may be a much smaller number than that of all
           keys. If the <literal>WHERE</literal> clause contains range
-          predicates (see the discussion in <xref linkend="explain"/>,
-          of the <literal>range</literal> join type), a loose index scan
+          predicates (see the discussion of the <literal>range</literal>
+          join type in <xref linkend="explain"/>), a loose index scan
           looks up the first key of each group that satisfies the range
           conditions, and again reads the least possible number of keys.
           This is possible under the following conditions:
@@ -4701,10 +4681,10 @@
           <listitem>
             <para>
               The <literal>GROUP BY</literal> includes the first
-              consecutive parts of the index (if instead of
+              consecutive parts of the index. (If, instead of
               <literal>GROUP BY</literal>, the query has a
               <literal>DISTINCT</literal> clause, all distinct
-              attributes refer to the beginning of the index).
+              attributes refer to the beginning of the index.)
             </para>
           </listitem>
 
@@ -4736,9 +4716,8 @@
         </para>
 
         <para>
-          The following queries provide several examples that fall into
-          this category, assuming that there is an index
-          <literal>idx(c1,c2,c3)</literal> on table
+          The following queries fall into this category, assuming that
+          there is an index <literal>idx(c1,c2,c3)</literal> on table
           <literal>t1(c1,c2,c3,c4)</literal>:
         </para>
 
@@ -4761,7 +4740,7 @@
 
           <listitem>
             <para>
-              There are other aggregate functions than
+              There are aggregate functions other than
               <literal>MIN()</literal> or <literal>MAX()</literal>, for
               example:
             </para>
@@ -5061,7 +5040,7 @@
 
 <programlisting>
 SELECT * FROM t1, t2 FORCE INDEX (<replaceable>index_for_column</replaceable>)
-    WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
+  WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
 </programlisting>
         </listitem>
 
@@ -5527,8 +5506,8 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
-    AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
+  WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
+  AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
 </programlisting>
         </listitem>
 
@@ -6548,8 +6527,8 @@
       <para>
         MySQL supports many different storage engines (table types) and
         row formats. For each table, you can decide which storage and
-        indexing method to use. Choosing the right table format for your
-        application may give you a big performance gain. See
+        indexing method to use. Choosing the proper table format for
+        your application may give you a big performance gain. See
         <xref linkend="storage-engines"/>.
       </para>
 
@@ -6603,15 +6582,15 @@
 
         <listitem>
           <para>
-            Starting with MySQL/InnoDB 5.0.3, <literal>InnoDB</literal>
-            tables use a more compact storage format. In earlier
-            versions of MySQL, <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 are created in the compact format
+            Starting with MySQL 5.0.3, <literal>InnoDB</literal> tables
+            use a more compact storage format. In earlier versions of
+            MySQL, <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
+            are created in the compact format
             (<literal>ROW_FORMAT=COMPACT</literal>). If you wish to
-            downgrade to older versions of MySQL/InnoDB, you can request
-            the old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
+            downgrade to older versions of MySQL, you can request the
+            old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
           </para>
 
           <para>
@@ -6856,15 +6835,15 @@
 SELECT * FROM test WHERE last_name='Widenius';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' AND first_name='Michael';
+  WHERE last_name='Widenius' AND first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND (first_name='Michael' OR first_name='Monty');
+  WHERE last_name='Widenius'
+  AND (first_name='Michael' OR first_name='Monty');
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND first_name &gt;='M' AND first_name &lt; 'N';
+  WHERE last_name='Widenius'
+  AND first_name &gt;='M' AND first_name &lt; 'N';
 </programlisting>
 
       <para>
@@ -6876,7 +6855,7 @@
 SELECT * FROM test WHERE first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' OR first_name='Michael';
+  WHERE last_name='Widenius' OR first_name='Michael';
 </programlisting>
 
       <para>
@@ -6975,7 +6954,7 @@
 
 <programlisting>
 SELECT MIN(<replaceable>key_part2</replaceable>),MAX(<replaceable>key_part2</replaceable>)
-    FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
+  FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
 </programlisting>
         </listitem>
 
@@ -7002,7 +6981,7 @@
 
 <programlisting>
 SELECT <replaceable>key_part3</replaceable> FROM <replaceable>tbl_name</replaceable> 
-    WHERE <replaceable>key_part1</replaceable>=1
+  WHERE <replaceable>key_part1</replaceable>=1
 </programlisting>
         </listitem>
 
@@ -7644,11 +7623,6 @@
 
         <title>&title-midpoint-insertion;</title>
 
-        <remark>
-          [JS] This continues to be the case for key management in 5.0,
-          right?
-        </remark>
-
         <para>
           By default, the key cache management system uses the LRU
           strategy for choosing key cache blocks to be evicted, but it

Modified: trunk/refman-5.0/porting.xml
===================================================================
--- trunk/refman-5.0/porting.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/porting.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -699,7 +699,7 @@
         happens, you should check all your tables with
         <command>myisamchk</command> (see
         <xref linkend="database-administration"/>), and test the queries
-        in the MySQL log files to see if one doesn't work. If you find
+        in the MySQL log files to see whether one fails. If you find
         such a query, try first upgrading to the newest MySQL version.
         If this doesn't help and you can't find anything in the
         <literal>mysql</literal> mail archive, you should report the bug

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/replication.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -1948,8 +1948,8 @@
 
           <listitem>
             <para>
-              Repeat the procedure later to see if you have better luck
-              next time.
+              Repeat the procedure later to see whether you have better
+              luck next time.
             </para>
           </listitem>
 
@@ -3885,8 +3885,8 @@
       <emphasis role="bold">A</emphasis>: With the currently available
       features, you would have to set up a master and a slave (or
       several slaves), and to write a script that monitors the master to
-      see if it is up. Then instruct your applications and the slaves to
-      change master in case of failure. Some suggestions:
+      check whether it is up. Then instruct your applications and the
+      slaves to change master in case of failure. Some suggestions:
     </para>
 
     <itemizedlist>

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4046,10 +4046,10 @@
             and the client issuing the <literal>INSERT DELAYED</literal>
             statement can then continue. If the table is in use, the
             server holds the rows. When the table is free, the server
-            begins inserting rows, checking periodically to see if there
-            are any new read requests for the table. If there are, the
-            delayed row queue is suspended until the table becomes free
-            again. See <xref linkend="insert-delayed"/>.
+            begins inserting rows, checking periodically to see whether
+            there are any new read requests for the table. If there are,
+            the delayed row queue is suspended until the table becomes
+            free again. See <xref linkend="insert-delayed"/>.
           </para>
         </listitem>
 
@@ -7057,7 +7057,7 @@
 </programlisting>
 
         <para>
-          is equivalent to :
+          is equivalent to:
         </para>
 
 <programlisting>

Modified: trunk/refman-5.1/connector-odbc.xml
===================================================================
--- trunk/refman-5.1/connector-odbc.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/connector-odbc.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -1451,8 +1451,8 @@
       <para>
         In case while configuring with thread-safe option, and gotten
         into a configure error; then look at the
-        <filename>config.log</filename> and see if it is due to the lack
-        of thread-libraries in the system; and supply one with LIBS
+        <filename>config.log</filename> and see whether it is due to the
+        lack of thread-libraries in the system; and supply one with LIBS
         options i.e.
       </para>
 

Modified: trunk/refman-5.1/custom-engine.xml
===================================================================
--- trunk/refman-5.1/custom-engine.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/custom-engine.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -10849,8 +10849,8 @@
 
       <para>
         If index == MAX_KEY then a check for table is made and if index
-        &lt; MAX_KEY then a check is made if the table has foreign keys
-        and if a foreign key uses this index (and thus the index cannot
+        &lt; MAX_KEY then a check is made whether the table has foreign keys
+        and whether a foreign key uses this index (and thus the index cannot
         be dropped).
       </para>
 
@@ -10860,7 +10860,7 @@
 
         <listitem>
           <para>
-            <literal>index</literal> Index to check if foreign key uses
+            <literal>index</literal> Index to check whether foreign key uses
             it
           </para>
         </listitem>

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/database-administration.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -6469,10 +6469,10 @@
               This variable applies to NDB. By default it is 0
               (<literal>OFF</literal>): If you execute a query such as
               <literal>SELECT * FROM t WHERE mycol = 42</literal>, where
-              <literal>mycol</literal> is an non-indexed column, the query
-              is executed as a full table scan on every NDB node. Each
-              node sends every row to the MySQL server, which applies
-              the <literal>WHERE</literal> condition. If
+              <literal>mycol</literal> is an non-indexed column, the
+              query is executed as a full table scan on every NDB node.
+              Each node sends every row to the MySQL server, which
+              applies the <literal>WHERE</literal> condition. If
               <literal>engine_condition_pushdown</literal> is set to 1
               (<literal>ON</literal>), the condition is <quote>pushed
               down</quote> to the storage engine and sent to the NDB
@@ -12054,9 +12054,9 @@
             users. The output of <command>mysqladmin
             processlist</command> shows the text of any executing
             queries currently being executed, so any user who is allowed
-            to run that command might be able to see if another user
-            issues an <literal>UPDATE user SET
-            password=PASSWORD('not_secure')</literal> query.
+            to run that command might be able to see whether another
+            user issues a statement such as <literal>UPDATE user SET
+            password=PASSWORD('not_secure')</literal>.
           </para>
 
           <para>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/innodb.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -5223,9 +5223,9 @@
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
-        Before removing them, you might want to examine them to see if
-        they contain useful information about the cause of abnormal
-        shutdowns. The
+        Before removing them, you might want to examine them to see
+        whether they contain useful information about the cause of
+        abnormal shutdowns. The
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
         <literal>innodb_status_file=1</literal> is set.

Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/installing.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -11180,8 +11180,8 @@
 
         <para>
           If the server fails to start up correctly, check the error log
-          file to see if you can find out why. Log files are located in
-          the data directory (typically <filename>C:\Program
+          file to see whether you can find out why. Log files are
+          located in the data directory (typically <filename>C:\Program
           Files\MySQL\MySQL Server &current-series;\data</filename> on
           Windows, <filename>/usr/local/mysql/data</filename> for a Unix
           binary distribution, and <filename>/usr/local/var</filename>
@@ -15269,8 +15269,8 @@
             <para>
               Many applications use setuid binaries so that you need to
               specify only a single user. See the documentation provided
-              with the application to see if this is the case for your
-              application.
+              with the application to see whether this is the case for
+              your application.
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4527,9 +4527,10 @@
             <para>
               It is rarely necessary to increase the size of this
               buffer. If there is such a need, then it is a good idea to
-              check if the disks can actually handle the load caused by
-              database update activity. A lack of sufficient disk space
-              cannot be overcome by increasing the size of this buffer.
+              check whether the disks can actually handle the load
+              caused by database update activity. A lack of sufficient
+              disk space cannot be overcome by increasing the size of
+              this buffer.
             </para>
 
             <para>
@@ -11118,7 +11119,7 @@
             evaluation. (That is, function transport is used, rather
             than data transport.) Please note that this feature is
             currently disabled by default (pending more thorough
-            testing), but it should work in most cases. This feature can            
+            testing), but it should work in most cases. This feature can
             be enabled through the use of the <literal>SET
             engine_condition_pushdown=On;</literal> statement.
             Alternatively, you can run <command>mysqld</command> with

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/optimization.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -744,7 +744,7 @@
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
         <literal>SELECT</literal> that uses indexes to find rows. You
-        can also use <literal>EXPLAIN</literal> to see whether the
+        can also use <literal>EXPLAIN</literal> to check whether the
         optimizer joins the tables in an optimal order. To force the
         optimizer to use a join order corresponding to the order in
         which the tables are named in the <literal>SELECT</literal>
@@ -952,7 +952,7 @@
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>primary_key</replaceable>=1;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
+  WHERE <replaceable>primary_key_part1</replaceable>=1 AND <replaceable>primary_key_part2</replaceable>=2;
 </programlisting>
             </listitem>
 
@@ -987,7 +987,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1029,7 +1029,7 @@
 
 SELECT * FROM <replaceable>ref_table</replaceable>,<replaceable>other_table</replaceable>
   WHERE <replaceable>ref_table</replaceable>.<replaceable>key_column_part1</replaceable>=<replaceable>other_table</replaceable>.<replaceable>column</replaceable>
-    AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
+  AND <replaceable>ref_table</replaceable>.<replaceable>key_column_part2</replaceable>=1;
 </programlisting>
             </listitem>
 
@@ -1050,7 +1050,7 @@
 
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable>
-WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
+  WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
 </programlisting>
 
               <para>
@@ -1140,16 +1140,16 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> = 10;
+  WHERE <replaceable>key_column</replaceable> = 10;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
+  WHERE <replaceable>key_column</replaceable> BETWEEN 10 and 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_column</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_column</replaceable> IN (10,20,30);
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
+  WHERE <replaceable>key_part1</replaceable>= 10 AND <replaceable>key_part2</replaceable> IN (10,20,30);
 </programlisting>
             </listitem>
 
@@ -1210,10 +1210,10 @@
             If this column is <literal>NULL</literal>, there are no
             relevant indexes. In this case, you may be able to improve
             the performance of your query by examining the
-            <literal>WHERE</literal> clause to see whether it refers to
-            some column or columns that would be suitable for indexing.
-            If so, create an appropriate index and check the query with
-            <literal>EXPLAIN</literal> again. See
+            <literal>WHERE</literal> clause to check whether it refers
+            to some column or columns that would be suitable for
+            indexing. If so, create an appropriate index and check the
+            query with <literal>EXPLAIN</literal> again. See
             <xref linkend="alter-table"/>.
           </para>
 
@@ -1629,10 +1629,10 @@
         of the <literal>EXPLAIN</literal> output. This should tell you
         roughly how many rows MySQL must examine to execute the query.
         If you restrict queries with the
-        <literal>max_join_size</literal> system variable, this product
-        also is used to determine which multiple-table
-        <literal>SELECT</literal> statements to execute. See
-        <xref linkend="server-parameters"/>.
+        <literal>max_join_size</literal> system variable, this row
+        product also is used to determine which multiple-table
+        <literal>SELECT</literal> statements to execute and which to
+        abort. See <xref linkend="server-parameters"/>.
       </para>
 
       <para>
@@ -1643,7 +1643,7 @@
 
       <para>
         Suppose that you have the <literal>SELECT</literal> statement
-        shown here and you plan to examine it using
+        shown here and that you plan to examine it using
         <literal>EXPLAIN</literal>:
       </para>
 
@@ -1785,9 +1785,9 @@
         Cartesian product of all the tables; that is, every combination
         of rows. This takes quite a long time, because the product of
         the number of rows in each table must be examined. For the case
-        at hand, this product is <literal>74 &times; 2135 &times; 74
-        &times; 3872 = 45,268,558,720</literal> rows. If the tables were
-        bigger, you can only imagine how long it would take.
+        at hand, this product is 74 &times; 2135 &times; 74 &times; 3872
+        = 45,268,558,720 rows. If the tables were bigger, you can only
+        imagine how long it would take.
       </para>
 
       <para>
@@ -1812,7 +1812,7 @@
 </programlisting>
 
       <para>
-        <literal>tt.ActualPC</literal> and
+        Now <literal>tt.ActualPC</literal> and
         <literal>et.EMPLOYID</literal> are both
         <literal>VARCHAR(15)</literal>. Executing the
         <literal>EXPLAIN</literal> statement again produces this result:
@@ -1833,7 +1833,7 @@
       <para>
         This is not perfect, but is much better: The product of the
         <literal>rows</literal> values is less by a factor of 74. This
-        version is executed in a couple of seconds.
+        version executes in a couple of seconds.
       </para>
 
       <para>
@@ -1849,7 +1849,8 @@
 </programlisting>
 
       <para>
-        <literal>EXPLAIN</literal> produces the output shown here:
+        After that modification, <literal>EXPLAIN</literal> produces the
+        output shown here:
       </para>
 
 <programlisting>
@@ -1863,13 +1864,10 @@
 </programlisting>
 
       <para>
-        This is almost as good as it can get.
-      </para>
-
-      <para>
-        The remaining problem is that, by default, MySQL assumes that
-        values in the <literal>tt.ActualPC</literal> column are evenly
-        distributed, and that is not the case for the
+        At this point, the query is optimized almost as well as
+        possible. The remaining problem is that, by default, MySQL
+        assumes that values in the <literal>tt.ActualPC</literal> column
+        are evenly distributed, and that is not the case for the
         <literal>tt</literal> table. Fortunately, it is easy to tell
         MySQL to analyze the key distribution:
       </para>
@@ -1878,18 +1876,9 @@
 mysql&gt; <userinput>ANALYZE TABLE tt;</userinput>
 </programlisting>
 
-<!--
-    
-<programlisting>
-shell&gt; <userinput>myisamchk -analyze PATH_TO_MYSQL_DATABASE/tt</userinput>
-shell&gt; <userinput>mysqladmin refresh</userinput>
-</programlisting>
-
--->
-
       <para>
-        The join is perfect, and <literal>EXPLAIN</literal> produces
-        this result:
+        With the additional index information, the join is perfect and
+        <literal>EXPLAIN</literal> produces this result:
       </para>
 
 <programlisting>
@@ -1906,8 +1895,10 @@
         Note that the <literal>rows</literal> column in the output from
         <literal>EXPLAIN</literal> is an educated guess from the MySQL
         join optimizer. You should check whether the numbers are even
-        close to the truth. If not, you may get better performance by
-        using <literal>STRAIGHT_JOIN</literal> in your
+        close to the truth by comparing the <literal>rows</literal>
+        product with the actual number of rows that the query returns.
+        If the numbers are quite different, you might get better
+        performance by using <literal>STRAIGHT_JOIN</literal> in your
         <literal>SELECT</literal> statement and trying to list the
         tables in a different order in the <literal>FROM</literal>
         clause.
@@ -1935,11 +1926,11 @@
       </indexterm>
 
       <para>
-        In most cases, you can estimate the performance by counting disk
-        seeks. For small tables, you can usually find a row in one disk
-        seek (because the index is probably cached). For bigger tables,
-        you can estimate that, using B-tree indexes, you need this many
-        seeks to find a row:
+        In most cases, you can estimate query performance by counting
+        disk seeks. For small tables, you can usually find a row in one
+        disk seek (because the index is probably cached). For bigger
+        tables, you can estimate that, using B-tree indexes, you need
+        this many seeks to find a row:
         <literal>log(<replaceable>row_count</replaceable>) /
         log(<replaceable>index_block_length</replaceable> / 3 &times; 2
         / (<replaceable>index_length</replaceable> +
@@ -1947,9 +1938,10 @@
       </para>
 
       <para>
-        In MySQL, an index block is usually 1024 bytes and the data
-        pointer is usually 4 bytes. For a 500,000-row table with an
-        index length of 3 bytes (medium integer), the formula indicates
+        In MySQL, an index block is usually 1,024 bytes and the data
+        pointer is usually four bytes. For a 500,000-row table with an
+        index length of three bytes (the size of
+        <literal>MEDIUMINT</literal>), the formula indicates
         <literal>log(500,000)/log(1024/3*2/(3+4)) + 1</literal> =
         <literal>4</literal> seeks.
       </para>
@@ -1963,7 +1955,7 @@
 
       <para>
         For writes, however, you need four seek requests to find where
-        to place the new index and normally two seeks to update the
+        to place a new index value and normally two seeks to update the
         index and write the row.
       </para>
 
@@ -2004,7 +1996,7 @@
         different tables should usually be done with indexes. You can
         use the <literal>EXPLAIN</literal> statement to determine which
         indexes are used for a <literal>SELECT</literal>. See
-        <xref linkend="mysql-indexes"/>, and <xref linkend="explain"/>.
+        <xref linkend="explain"/>, and <xref linkend="mysql-indexes"/>.
       </para>
 
       <para>
@@ -2036,11 +2028,11 @@
           <para>
             To sort an index and data according to an index, use
             <command>myisamchk --sort-index --sort-records=1</command>
-            (if you want to sort on index 1). This is a good way to make
-            queries faster if you have a unique index from which you
-            want to read all rows in order according to the index. Note
-            that the first time you sort a large table this way, it may
-            take a long time.
+            (assuming that you want to sort on index 1). This is a good
+            way to make queries faster if you have a unique index from
+            which you want to read all rows in order according to the
+            index. Note that the first time you sort a large table this
+            way, it may take a long time.
           </para>
         </listitem>
 
@@ -2070,13 +2062,13 @@
       </para>
 
       <para>
-        Note that work on the MySQL optimizer is ongoing, so this
-        section is incomplete. MySQL performs a great many
-        optimizations, not all of which are documented here.
+        Work on the MySQL optimizer is ongoing, so this section is
+        incomplete. MySQL performs a great many optimizations, not all
+        of which are documented here.
       </para>
 
       <para>
-        Some of the optimizations performed by MySQL are listed here:
+        Some of the optimizations performed by MySQL follow:
       </para>
 
       <itemizedlist>
@@ -2145,8 +2137,9 @@
           <para>
             <literal>HAVING</literal> is merged with
             <literal>WHERE</literal> if you do not use <literal>GROUP
-            BY</literal> or group functions (<literal>COUNT()</literal>,
-            <literal>MIN()</literal>, and so on).
+            BY</literal> or aggregate functions
+            (<literal>COUNT()</literal>, <literal>MIN()</literal>, and
+            so on).
           </para>
         </listitem>
 
@@ -2201,7 +2194,7 @@
 <programlisting>
 SELECT * FROM t WHERE <replaceable>primary_key</replaceable>=1;
 SELECT * FROM t1,t2
-    WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
+  WHERE t1.<replaceable>primary_key</replaceable>=1 AND t2.<replaceable>primary_key</replaceable>=t1.id;
 </programlisting>
         </listitem>
 
@@ -2227,8 +2220,8 @@
 
         <listitem>
           <para>
-            If you use <literal>SQL_SMALL_RESULT</literal>, MySQL uses
-            an in-memory temporary table.
+            If you use the <literal>SQL_SMALL_RESULT</literal> option,
+            MySQL uses an in-memory temporary table.
           </para>
         </listitem>
 
@@ -2237,11 +2230,11 @@
             Each table index is queried, and the best index is used
             unless the optimizer believes that it is more efficient to
             use a table scan. At one time, a scan was used based on
-            whether the best index spanned more than 30% of the table.
-            The optimizer is more complex and bases its estimate on
-            additional factors such as table size, number of rows, and
-            I/O block size, so a fixed percentage no longer determines
-            the choice between using an index or a scan.
+            whether the best index spanned more than 30% of the table,
+            but a fixed percentage no longer determines the choice
+            between using an index or a scan. The optimizer now is more
+            complex and bases its estimate on additional factors such as
+            table size, number of rows, and I/O block size.
           </para>
         </listitem>
 
@@ -2273,17 +2266,17 @@
 SELECT MIN(<replaceable>key_part1</replaceable>),MAX(<replaceable>key_part1</replaceable>) FROM <replaceable>tbl_name</replaceable>;
 
 SELECT MAX(<replaceable>key_part2</replaceable>) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable>;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... LIMIT 10;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... LIMIT 10;
 </programlisting>
 
       <para>
-        The following queries are resolved using only the index tree,
+        MySQL resolves the following queries using only the index tree,
         assuming that the indexed columns are numeric:
       </para>
 
@@ -2291,7 +2284,7 @@
 SELECT <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=<replaceable>val</replaceable>;
 
 SELECT COUNT(*) FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>val1</replaceable> AND <replaceable>key_part2</replaceable>=<replaceable>val2</replaceable>;
 
 SELECT <replaceable>key_part2</replaceable> FROM <replaceable>tbl_name</replaceable> GROUP BY <replaceable>key_part1</replaceable>;
 </programlisting>
@@ -2303,10 +2296,10 @@
 
 <programlisting>
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
 
 SELECT ... FROM <replaceable>tbl_name</replaceable>
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC, ... ;
 </programlisting>
 
     </section>
@@ -2319,9 +2312,9 @@
         The <literal>range</literal> access method uses a single index
         to retrieve a subset of table rows that are contained within one
         or several index value intervals. It can be used for a
-        single-part or multiple-part index. A detailed description of
-        how intervals are extracted from the <literal>WHERE</literal>
-        clause is given in the following sections.
+        single-part or multiple-part index. The following sections give
+        a detailed description of how intervals are extracted from the
+        <literal>WHERE</literal> clause.
       </para>
 
       <section id="range-access-single-part">
@@ -2420,16 +2413,16 @@
 
 <programlisting>
 SELECT * FROM t1
-    WHERE <replaceable>key_col</replaceable> &gt; 1 
-    AND <replaceable>key_col</replaceable> &lt; 10;
+  WHERE <replaceable>key_col</replaceable> &gt; 1 
+  AND <replaceable>key_col</replaceable> &lt; 10;
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> = 1 
-    OR <replaceable>key_col</replaceable> IN (15,18,20);
+  WHERE <replaceable>key_col</replaceable> = 1 
+  OR <replaceable>key_col</replaceable> IN (15,18,20);
 
 SELECT * FROM t1 
-    WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
-    OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
+  WHERE <replaceable>key_col</replaceable> LIKE 'ab%' 
+  OR <replaceable>key_col</replaceable> BETWEEN 'bar' AND 'foo';
 </programlisting>
 
         <para>
@@ -2447,16 +2440,16 @@
         </para>
 
         <para>
-          For example, consider the following statement, where
+          Consider the following statement, where
           <literal>key1</literal> is an indexed column and
           <literal>nonkey</literal> is not indexed:
         </para>
 
 <programlisting>
 SELECT * FROM t1 WHERE
-   (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
-   (key1 &lt; 'bar' AND nonkey = 4) OR
-   (key1 &lt; 'uux' AND key1 &gt; 'z');
+  (key1 &lt; 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
+  (key1 &lt; 'bar' AND nonkey = 4) OR
+  (key1 &lt; 'uux' AND key1 &gt; 'z');
 </programlisting>
 
         <para>
@@ -2482,7 +2475,7 @@
             <para>
               Remove <literal>nonkey = 4</literal> and <literal>key1
               LIKE '%b'</literal> because they cannot be used for a
-              range scan. The right way to remove them is to replace
+              range scan. The correct way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
               any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
@@ -2528,7 +2521,7 @@
 
             <para>
               Removing unnecessary <literal>TRUE</literal> and
-              <literal>FALSE</literal> constants, we obtain
+              <literal>FALSE</literal> constants, we obtain:
             </para>
 
 <programlisting>
@@ -2550,8 +2543,8 @@
         </orderedlist>
 
         <para>
-          In general (and as demonstrated in the example), the condition
-          used for a range scan is less restrictive than the
+          In general (and as demonstrated by the preceding example), the
+          condition used for a range scan is less restrictive than the
           <literal>WHERE</literal> clause. MySQL performs an additional
           check to filter out rows that satisfy the range condition but
           not the full <literal>WHERE</literal> clause.
@@ -2604,7 +2597,7 @@
         </para>
 
 <programlisting>
-(1, -inf, -inf) &lt;= (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>) &lt; (1, +inf, +inf)
+(1,-inf,-inf) &lt;= (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; (1,+inf,+inf)
 </programlisting>
 
         <para>
@@ -2649,22 +2642,19 @@
               <literal>IS NULL</literal> comparison operators, and the
               conditions cover all index parts. (That is, there are
               <replaceable>N</replaceable> conditions, one for each part
-              of an <replaceable>N</replaceable>-part index.)
-            </para>
-
-            <para>
-              See <xref linkend="range-access-single-part"/>, for the
-              definition of what is considered to be a constant.
-            </para>
-
-            <para>
-              For example, the following is a range condition for a
+              of an <replaceable>N</replaceable>-part index.) For
+              example, the following is a range condition for a
               three-part <literal>HASH</literal> index:
             </para>
 
 <programlisting>
 <replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> IS NULL AND <replaceable>key_part3</replaceable> = 'foo'
 </programlisting>
+
+            <para>
+              For the definition of what is considered to be a constant,
+              see <xref linkend="range-access-single-part"/>.
+            </para>
           </listitem>
 
           <listitem>
@@ -2697,9 +2687,7 @@
             </para>
 
 <programlisting>
-('foo', 10, 10)
-   &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>, <replaceable>key_part3</replaceable>)
-      &lt; ('foo', +inf, +inf)
+('foo',10,10) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,<replaceable>key_part3</replaceable>) &lt; ('foo',+inf,+inf)
 </programlisting>
 
             <para>
@@ -2724,17 +2712,16 @@
             </para>
 
 <programlisting>
-(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2)
-OR (<replaceable>key_part1</replaceable> &gt; 5)
+(<replaceable>key_part1</replaceable> = 1 AND <replaceable>key_part2</replaceable> &lt; 2) OR (<replaceable>key_part1</replaceable> &gt; 5)
 </programlisting>
 
             <para>
-              The intervals is:
+              The intervals are:
             </para>
 
 <programlisting>
-(1, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>) &lt; (1, 2)
-(5, -inf) &lt; (<replaceable>key_part1</replaceable>, <replaceable>key_part2</replaceable>)
+(1,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>) &lt; (1,2)
+(5,-inf) &lt; (<replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>)
 </programlisting>
 
             <para>
@@ -2762,7 +2749,7 @@
 </programlisting>
 
             <para>
-              But in fact, the condition is converted to this:
+              But, in fact, the condition is converted to this:
             </para>
 
 <programlisting>
@@ -2782,8 +2769,8 @@
         <para>
           <xref linkend="range-access-single-part"/>, describes how
           optimizations are performed to combine or eliminate intervals
-          for range conditions on single-part index. Analogous steps are
-          performed for range conditions on multiple-part keys.
+          for range conditions on a single-part index. Analogous steps
+          are performed for range conditions on multiple-part indexes.
         </para>
 
 <!--  
@@ -2797,13 +2784,10 @@
 -->
 
         <remark role="todo">
-          resolve this
+          Resolve this: The text above conflicts with section
+          mysql-indexes.
         </remark>
 
-        <remark role="note">
-          The text above conflicts with section mysql-indexes.
-        </remark>
-
       </section>
 
     </section>
@@ -2833,11 +2817,12 @@
       </para>
 
       <para>
-        In <literal>EXPLAIN</literal> output, this method appears as
-        <literal>index_merge</literal> in the <literal>type</literal>
-        column. In this case, the <literal>key</literal> column contains
-        a list of indexes used, and <literal>key_len</literal> contains
-        a list of the longest key parts for those indexes.
+        In <literal>EXPLAIN</literal> output, the Index Merge method
+        appears as <literal>index_merge</literal> in the
+        <literal>type</literal> column. In this case, the
+        <literal>key</literal> column contains a list of indexes used,
+        and <literal>key_len</literal> contains a list of the longest
+        key parts for those indexes.
       </para>
 
       <para>
@@ -2848,15 +2833,15 @@
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE (<replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20) AND <replaceable>non_key_part</replaceable>=30;
+  WHERE (<replaceable>key_part1</replaceable> = 10 OR <replaceable>key_part2</replaceable> = 20) AND <replaceable>non_key_part</replaceable>=30;
 
 SELECT * FROM t1, t2
-    WHERE (t1.<replaceable>key1</replaceable> IN (1,2) OR t1.<replaceable>key2</replaceable> LIKE '<replaceable>value</replaceable>%')
-    AND t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable>;
+  WHERE (t1.<replaceable>key1</replaceable> IN (1,2) OR t1.<replaceable>key2</replaceable> LIKE '<replaceable>value</replaceable>%')
+  AND t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable>;
 
 SELECT * FROM t1, t2
-    WHERE t1.<replaceable>key1</replaceable>=1
-    AND (t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable> OR t2.<replaceable>key2</replaceable>=t1.<replaceable>some_col2</replaceable>);
+  WHERE t1.<replaceable>key1</replaceable>=1
+  AND (t2.<replaceable>key1</replaceable>=t1.<replaceable>some_col</replaceable> OR t2.<replaceable>key2</replaceable>=t1.<replaceable>some_col2</replaceable>);
 </programlisting>
 
       <para>
@@ -2869,19 +2854,19 @@
 
         <listitem>
           <para>
-            intersection
+            <literal>Using intersect(&hellip;)</literal>
           </para>
         </listitem>
 
         <listitem>
           <para>
-            union
+            <literal>Using union(&hellip;)</literal>
           </para>
         </listitem>
 
         <listitem>
           <para>
-            sort-union
+            <literal>Using sort_union(&hellip;)</literal>
           </para>
         </listitem>
 
@@ -2912,7 +2897,7 @@
             For this query, two plans are possible:
           </para>
 
-          <orderedlist>
+          <itemizedlist>
 
             <listitem>
               <para>
@@ -2928,23 +2913,22 @@
               </para>
             </listitem>
 
-          </orderedlist>
+          </itemizedlist>
 
           <para>
-            However, the optimizer only considers the second plan. If
+            However, the optimizer considers only the second plan. If
             that is not what you want, you can make the optimizer
-            consider <literal>index_merge</literal> by using
-            <literal>IGNORE INDEX</literal> or <literal>FORCE
-            INDEX</literal>. The following queries are executed using
-            Index Merge:
+            consider Index Merge by using <literal>IGNORE
+            INDEX</literal> or <literal>FORCE INDEX</literal>. The
+            following queries are executed using Index Merge:
           </para>
 
 <programlisting>
 SELECT * FROM t1 FORCE INDEX(goodkey1,goodkey2)
-WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
+  WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
 
 SELECT * FROM t1 IGNORE INDEX(badkey)
-WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
+  WHERE (goodkey1 &lt; 10 OR goodkey2 &lt; 20) AND badkey &lt; 30;
 </programlisting>
         </listitem>
 
@@ -2965,9 +2949,9 @@
       </itemizedlist>
 
       <para>
-        The choice between different possible variants of the
-        <literal>index_merge</literal> access method and other access
-        methods is based on cost estimates of various available options.
+        The choice between different possible variants of the Index
+        Merge access method and other access methods is based on cost
+        estimates of various available options.
       </para>
 
       <section id="index-merge-intersection">
@@ -3006,14 +2990,14 @@
         </itemizedlist>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
 SELECT * FROM <replaceable>innodb_table</replaceable> WHERE <replaceable>primary_key</replaceable> &lt; 10 AND <replaceable>key_col1</replaceable>=20;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-WHERE (<replaceable>key1_part1</replaceable>=1 AND <replaceable>key1_part2</replaceable>=2) AND <replaceable>key2</replaceable>=2;
+  WHERE (<replaceable>key1_part1</replaceable>=1 AND <replaceable>key1_part2</replaceable>=2) AND <replaceable>key2</replaceable>=2;
 </programlisting>
 
         <para>
@@ -3024,10 +3008,10 @@
 
         <para>
           If all columns used in the query are covered by the used
-          indexes, full table rows are not retrieved and
+          indexes, full table rows are not retrieved
           (<literal>EXPLAIN</literal> output contains <literal>Using
           index</literal> in <literal>Extra</literal> field in this
-          case). Here is an example of such query:
+          case). Here is an example of such a query:
         </para>
 
 <programlisting>
@@ -3094,7 +3078,7 @@
         </itemizedlist>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
@@ -3118,7 +3102,7 @@
         </para>
 
         <para>
-          Here are some examples:
+          Examples:
         </para>
 
 <programlisting>
@@ -3153,19 +3137,23 @@
       <para>
         MySQL can perform the same optimization on
         <replaceable>col_name</replaceable> <literal>IS NULL</literal>
-        that it can use with <replaceable>col_name</replaceable>
+        that it can use for <replaceable>col_name</replaceable>
         <literal>=</literal> <replaceable>constant_value</replaceable>.
         For example, MySQL can use indexes and ranges to search for
         <literal>NULL</literal> with <literal>IS NULL</literal>.
       </para>
 
+      <para>
+        Examples:
+      </para>
+
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> IS NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_col</replaceable> &lt;=&gt; NULL;
 
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
+  WHERE <replaceable>key_col</replaceable>=<replaceable>const1</replaceable> OR <replaceable>key_col</replaceable>=<replaceable>const2</replaceable> OR <replaceable>key_col</replaceable> IS NULL;
 </programlisting>
 
       <para>
@@ -3206,14 +3194,14 @@
 SELECT * FROM t1, t2 WHERE t1.a=t2.a OR t2.a IS NULL;
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
+  WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
 
 SELECT * FROM t1, t2
-    WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
+  WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
 
 SELECT * FROM t1, t2
-    WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
-    OR (t1.a=t2.a AND t2.a IS NULL AND ...);
+  WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
+  OR (t1.a=t2.a AND t2.a IS NULL AND ...);
 </programlisting>
 
       <para>
@@ -3257,9 +3245,9 @@
       </para>
 
       <para>
-        Note that because <literal>DISTINCT</literal> may use
-        <literal>GROUP BY</literal>, you should be aware of how MySQL
-        works with columns in <literal>ORDER BY</literal> or
+        Because <literal>DISTINCT</literal> may use <literal>GROUP
+        BY</literal>, you should be aware of how MySQL works with
+        columns in <literal>ORDER BY</literal> or
         <literal>HAVING</literal> clauses that are not part of the
         selected columns. See <xref linkend="group-by-hidden-fields"/>.
       </para>
@@ -3299,8 +3287,8 @@
         <literal>t1</literal> is used before <literal>t2</literal>
         (which you can check with <literal>EXPLAIN</literal>), MySQL
         stops reading from <literal>t2</literal> (for any particular row
-        in <literal>t1</literal>) when the first row in
-        <literal>t2</literal> is found:
+        in <literal>t1</literal>) when it finds the first row in
+        <literal>t2</literal>:
       </para>
 
 <programlisting>
@@ -3323,16 +3311,16 @@
       </indexterm>
 
       <para>
-        An <literal><replaceable>A</replaceable> LEFT JOIN
-        <replaceable>B</replaceable> join_condition</literal> is
-        implemented in MySQL as follows:
+        MySQL implements an <literal><replaceable>A</replaceable> LEFT
+        JOIN <replaceable>B</replaceable> join_condition</literal> as
+        follows:
       </para>
 
       <itemizedlist>
 
         <listitem>
           <para>
-            Table <literal>B</literal> is set to depend on table
+            Table <replaceable>B</replaceable> is set to depend on table
             <replaceable>A</replaceable> and all tables on which
             <replaceable>A</replaceable> depends.
           </para>
@@ -3399,15 +3387,15 @@
       </itemizedlist>
 
       <para>
-        <literal>RIGHT JOIN</literal> is implemented analogously to
-        <literal>LEFT JOIN</literal>, with the roles of the tables
-        reversed.
+        The implementation of <literal>RIGHT JOIN</literal> is analogous
+        to that of <literal>LEFT JOIN</literal> with the roles of the
+        tables reversed.
       </para>
 
       <para>
         The join optimizer calculates the order in which tables should
         be joined. The table read order forced by <literal>LEFT
-        JOIN</literal> and <literal>STRAIGHT_JOIN</literal> helps the
+        JOIN</literal> or <literal>STRAIGHT_JOIN</literal> helps the
         join optimizer do its work much more quickly, because there are
         fewer table permutations to check. Note that this means that if
         you do a query of the following type, MySQL does a full scan on
@@ -3417,32 +3405,29 @@
 
 <programlisting>
 SELECT *
-    FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        The fix in this case is reverse the order in
+        The fix in this case is reverse the order in which
         <literal>a</literal> and <literal>b</literal> are listed in the
         <literal>FROM</literal> clause:
       </para>
 
 <programlisting>
 SELECT *
-    FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
-    WHERE b.key=d.key;
+  FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
+  WHERE b.key=d.key;
 </programlisting>
 
       <para>
-        MySQL performs the following <literal>LEFT JOIN</literal>
-        optimization: If the <literal>WHERE</literal> condition is
-        always false for the generated <literal>NULL</literal> row, the
-        <literal>LEFT JOIN</literal> is changed to a normal join.
-      </para>
-
-      <para>
-        For example, the <literal>WHERE</literal> clause would be false
-        in the following query if <literal>t2.column1</literal> were
+        For a <literal>LEFT JOIN</literal>, if the
+        <literal>WHERE</literal> condition is always false for the
+        generated <literal>NULL</literal> row, the <literal>LEFT
+        JOIN</literal> is changed to a normal join. For example, the
+        <literal>WHERE</literal> clause would be false in the following
+        query if <literal>t2.column1</literal> were
         <literal>NULL</literal>:
       </para>
 
@@ -3460,9 +3445,9 @@
 
       <para>
         This can be made faster because MySQL can use table
-        <literal>t2</literal> before table <literal>t1</literal> if this
-        would result in a better query plan. To force a specific table
-        order, use <literal>STRAIGHT_JOIN</literal>.
+        <literal>t2</literal> before table <literal>t1</literal> if
+        doing so would result in a better query plan. To force a
+        specific table order, use <literal>STRAIGHT_JOIN</literal>.
       </para>
 
     </section>
@@ -3481,22 +3466,19 @@
         The syntax of <replaceable>table_factor</replaceable> is
         extended in comparison with the SQL Standard. The latter accepts
         only <replaceable>table_reference</replaceable>, not a list of
-        them inside a pair of parentheses.
+        them inside a pair of parentheses. This is a conservative
+        extension if we consider each comma in a list of
+        <replaceable>table_reference</replaceable> items as equivalent
+        to an inner join. For example:
       </para>
 
-      <para>
-        This is a conservative extension if we consider each comma in a
-        list of <replaceable>table_reference</replaceable> items as
-        equivalent to an inner join. For example:
-      </para>
-
 <programlisting>
 SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                  ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
 </programlisting>
 
       <para>
-        is equivalent to :
+        is equivalent to:
       </para>
 
 <programlisting>
@@ -3507,7 +3489,7 @@
       <para>
         In MySQL, <literal>CROSS JOIN</literal> is a syntactic
         equivalent to <literal>INNER JOIN</literal> (they can replace
-        each other. In standard SQL, they are not equivalent.
+        each other). In standard SQL, they are not equivalent.
         <literal>INNER JOIN</literal> is used with an
         <literal>ON</literal> clause; <literal>CROSS JOIN</literal> is
         used otherwise.
@@ -3618,11 +3600,8 @@
 </programlisting>
 
       <para>
-        For the given table states, the first expression returns rows
-        <literal>{1,1,101,101}</literal>,
-        <literal>{2,NULL,NULL,NULL}</literal>, whereas the second
-        expression returns rows <literal>{1,1,101,101}</literal>,
-        <literal>{2,NULL,NULL,101}</literal>:
+        For the given table states, the two expressions return different
+        sets of rows:
       </para>
 
 <programlisting>
@@ -3654,7 +3633,7 @@
       <para>
         More exactly, we cannot ignore parentheses in the right operand
         of the left outer join operation and in the left operand of a
-        right join operation. In other words, we can't ignore
+        right join operation. In other words, we cannot ignore
         parentheses for the inner table expressions of outer join
         operations. Parentheses for the other operand (operand for the
         outer table) can be ignored.
@@ -3669,7 +3648,7 @@
 </programlisting>
 
       <para>
-        is equivalent to the expression
+        is equivalent to this expression:
       </para>
 
 <programlisting>
@@ -3685,8 +3664,8 @@
       <para>
         Whenever the order of execution of the join operations in a join
         expression (<replaceable>join_table</replaceable>) is not from
-        left to right, we talk about nested joins. Thus, the following
-        queries:
+        left to right, we talk about nested joins. Consider the
+        following queries:
       </para>
 
 <programlisting>
@@ -3698,7 +3677,7 @@
 </programlisting>
 
       <para>
-        the join tables:
+        Those queries are considered to contain these nested joins:
       </para>
 
 <programlisting>
@@ -3707,15 +3686,15 @@
 </programlisting>
 
       <para>
-        are considered as nested. The nested join is formed in the first
-        query with a left join operation, whereas in the second query it
-        is formed with an inner join operation.
+        The nested join is formed in the first query with a left join
+        operation, whereas in the second query it is formed with an
+        inner join operation.
       </para>
 
       <para>
         In the first query, the parentheses can be omitted: The
         grammatical structure of the join expression will dictate the
-        same order of execution for join operations. Yet for the second
+        same order of execution for join operations. For the second
         query, the parentheses cannot be omitted, although the join
         expression here can be interpreted unambiguously without them.
         (In our extended syntax the parentheses in <literal>(t2,
@@ -3737,38 +3716,27 @@
           <para>
             For join expressions involving only inner joins (and not
             outer joins), parentheses can be removed. You can remove
-            parentheses and evaluate left to right (or in fact, you can
+            parentheses and evaluate left to right (or, in fact, you can
             evaluate the tables in any order).
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The same is not true, in general, for outer joins. Removal
-            of parentheses may change the result.
+            The same is not true, in general, for outer joins or for
+            outer joins mixed with inner joins. Removal of parentheses
+            may change the result.
           </para>
         </listitem>
 
-        <listitem>
-          <para>
-            The same also is not true, in general, for outer joins mixed
-            with inner joins. Removal of parentheses may change the
-            result.
-          </para>
-        </listitem>
-
       </itemizedlist>
 
       <para>
         Queries with nested outer joins are executed in the same
         pipeline manner as queries with inner joins. More exactly, a
-        variation of the nested-loop join algorithm is exploited. Let's
-        recall by what algorithmic schema the nested-loop join executes
-        a query.
-      </para>
-
-      <para>
-        Suppose that we have a join query over 3 tables
+        variation of the nested-loop join algorithm is exploited. Recall
+        by what algorithmic schema the nested-loop join executes a
+        query. Suppose that we have a join query over 3 tables
         <literal>T1,T2,T3</literal> of the form:
       </para>
 
@@ -3787,7 +3755,7 @@
 
       <para>
         The nested-loop join algorithm would execute this query in the
-        following way:
+        following manner:
       </para>
 
 <programlisting>
@@ -3828,7 +3796,7 @@
 </programlisting>
 
       <para>
-        For this query we modify the nested-loop pattern to get:
+        For this query, we modify the nested-loop pattern to get:
       </para>
 
 <programlisting>
@@ -3936,7 +3904,7 @@
 </programlisting>
 
       <para>
-        and
+        and:
       </para>
 
 <programlisting>
@@ -3969,7 +3937,7 @@
       </para>
 
       <para>
-        When discussing about nested-loop algorithm for inner joins, we
+        When discussing the nested-loop algorithm for inner joins, we
         omitted some details whose impact on the performance of query
         execution may be huge. We did not mention so-called
         <quote>pushed-down</quote> conditions. Suppose that our
@@ -4006,14 +3974,14 @@
         be evaluated. If <literal>C1(T1)</literal> is a very restrictive
         condition, this condition pushdown may greatly reduce the number
         of rows from table <literal>T1</literal> passed to the inner
-        loops. As a result, the execution time for query may improve
+        loops. As a result, the execution time for the query may improve
         immensely.
       </para>
 
       <para>
         For a query with outer joins, the <literal>WHERE</literal>
-        condition is to be checked only after it has been found out that
-        the current row from the outer table has a match in the inner
+        condition is to be checked only after it has been found that the
+        current row from the outer table has a match in the inner
         tables. Thus, the optimization with pushing condition out of the
         inner nested loops cannot be applied directly to queries with
         outer joins. Here we have to introduce conditional pushed-down
@@ -4022,7 +3990,7 @@
       </para>
 
       <para>
-        For our example with outer joins with
+        For our example with outer joins with:
       </para>
 
 <programlisting>
@@ -4065,7 +4033,7 @@
         In general, pushed-down predicates can be extracted from join
         conditions such as <literal>P1(T1,T2)</literal> and
         <literal>P(T2,T3)</literal>. In this case, a pushed-down
-        predicates are guarded also by a flag that prevents checking the
+        predicate is guarded also by a flag that prevents checking the
         predicate for the <literal>NULL</literal>-complemented row
         generated by the corresponding outer join operation.
       </para>
@@ -4336,7 +4304,7 @@
 
       <para>
         When trying to convert an embedded outer join operation in a
-        query, we have to take into account the join condition for the
+        query, we must take into account the join condition for the
         embedding outer join together with the <literal>WHERE</literal>
         condition. In the query:
       </para>
@@ -4386,18 +4354,18 @@
 
 <programlisting>
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
+  ORDER BY <replaceable>key_part1</replaceable>,<replaceable>key_part2</replaceable>,... ;
     
 SELECT * FROM t1 
-    WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
-    ORDER BY <replaceable>key_part2</replaceable>;
+  WHERE <replaceable>key_part1</replaceable>=<replaceable>constant</replaceable> 
+  ORDER BY <replaceable>key_part2</replaceable>;
     
 SELECT * FROM t1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
     
 SELECT * FROM t1
-    WHERE <replaceable>key_part1</replaceable>=1 
-    ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
+  WHERE <replaceable>key_part1</replaceable>=1 
+  ORDER BY <replaceable>key_part1</replaceable> DESC, <replaceable>key_part2</replaceable> DESC;
 </programlisting>
 
       <para>
@@ -4511,7 +4479,7 @@
         <listitem>
           <para>
             Read the rows that match the <literal>WHERE</literal>
-            clause, as before.
+            clause.
           </para>
         </listitem>
 
@@ -4554,9 +4522,9 @@
       </para>
 
       <para>
-        If you want to increase <literal>ORDER BY</literal> speed, first
-        see whether you can get MySQL to use indexes rather than an
-        extra sorting phase. If this is not possible, you can try the
+        If you want to increase <literal>ORDER BY</literal> speed, check
+        whether you can get MySQL to use indexes rather than an extra
+        sorting phase. If this is not possible, you can try the
         following strategies:
       </para>
 
@@ -4595,6 +4563,16 @@
       </itemizedlist>
 
       <para>
+        <indexterm>
+          <primary>ORDER BY</primary>
+          <secondary>NULL</secondary>
+        </indexterm>
+
+        <indexterm>
+          <primary>NULL</primary>
+          <secondary>ORDER BY</secondary>
+        </indexterm>
+
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
         <replaceable>col2</replaceable>, &hellip;</literal> queries as
@@ -4644,11 +4622,12 @@
         The most important preconditions for using indexes for
         <literal>GROUP BY</literal> are that all <literal>GROUP
         BY</literal> columns reference attributes from the same index,
-        and the index stores its keys in order (for example, this is a
-        B-Tree index, and not a HASH index). Whether usage of temporary
-        tables can be replaced by index access also depends on which
-        parts of an index are used in a query, the conditions specified
-        for these parts, and the selected aggregate functions.
+        and that the index stores its keys in order (for example, this
+        is a <literal>BTREE</literal> index and not a
+        <literal>HASH</literal> index). Whether use of temporary tables
+        can be replaced by index access also depends on which parts of
+        an index are used in a query, the conditions specified for these
+        parts, and the selected aggregate functions.
       </para>
 
       <para>
@@ -4664,10 +4643,11 @@
         <title>&title-loose-index-scan;</title>
 
         <para>
-          The most efficient way is when the index is used to directly
-          retrieve the group fields. With this access method, MySQL uses
-          the property of some index types (for example, B-Trees) that
-          the keys are ordered. This property enables use of lookup
+          The most efficient way to process <literal>GROUP BY</literal>
+          is when the index is used to directly retrieve the group
+          fields. With this access method, MySQL uses the property of
+          some index types that the keys are ordered (for example,
+          <literal>BTREE</literal>). This property enables use of lookup
           groups in an index without having to consider all keys in the
           index that satisfy all <literal>WHERE</literal> conditions.
           This access method considers only a fraction of the keys in an
@@ -4676,8 +4656,8 @@
           clause, a loose index scan reads as many keys as the number of
           groups, which may be a much smaller number than that of all
           keys. If the <literal>WHERE</literal> clause contains range
-          predicates (see the discussion in <xref linkend="explain"/>,
-          of the <literal>range</literal> join type), a loose index scan
+          predicates (see the discussion of the <literal>range</literal>
+          join type in <xref linkend="explain"/>), a loose index scan
           looks up the first key of each group that satisfies the range
           conditions, and again reads the least possible number of keys.
           This is possible under the following conditions:
@@ -4694,10 +4674,10 @@
           <listitem>
             <para>
               The <literal>GROUP BY</literal> includes the first
-              consecutive parts of the index (if instead of
+              consecutive parts of the index. (If, instead of
               <literal>GROUP BY</literal>, the query has a
               <literal>DISTINCT</literal> clause, all distinct
-              attributes refer to the beginning of the index).
+              attributes refer to the beginning of the index.)
             </para>
           </listitem>
 
@@ -4729,9 +4709,8 @@
         </para>
 
         <para>
-          The following queries provide several examples that fall into
-          this category, assuming that there is an index
-          <literal>idx(c1,c2,c3)</literal> on table
+          The following queries fall into this category, assuming that
+          there is an index <literal>idx(c1,c2,c3)</literal> on table
           <literal>t1(c1,c2,c3,c4)</literal>:
         </para>
 
@@ -4754,7 +4733,7 @@
 
           <listitem>
             <para>
-              There are other aggregate functions than
+              There are aggregate functions other than
               <literal>MIN()</literal> or <literal>MAX()</literal>, for
               example:
             </para>
@@ -5054,7 +5033,7 @@
 
 <programlisting>
 SELECT * FROM t1, t2 FORCE INDEX (<replaceable>index_for_column</replaceable>)
-    WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
+  WHERE t1.<replaceable>col_name</replaceable>=t2.<replaceable>col_name</replaceable>;
 </programlisting>
         </listitem>
 
@@ -5520,8 +5499,8 @@
 
 <programlisting>
 SELECT * FROM <replaceable>tbl_name</replaceable>
-    WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
-    AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
+  WHERE <replaceable>hash_col</replaceable>=MD5(CONCAT(<replaceable>col1</replaceable>,<replaceable>col2</replaceable>))
+  AND <replaceable>col1</replaceable>='<replaceable>constant</replaceable>' AND <replaceable>col2</replaceable>='<replaceable>constant</replaceable>';
 </programlisting>
         </listitem>
 
@@ -6540,8 +6519,8 @@
       <para>
         MySQL supports many different storage engines (table types) and
         row formats. For each table, you can decide which storage and
-        indexing method to use. Choosing the right table format for your
-        application may give you a big performance gain. See
+        indexing method to use. Choosing the proper table format for
+        your application may give you a big performance gain. See
         <xref linkend="storage-engines"/>.
       </para>
 
@@ -6595,15 +6574,15 @@
 
         <listitem>
           <para>
-            In MySQL/InnoDB, <literal>InnoDB</literal> tables use a more
-            compact storage format. In earlier versions of MySQL,
+            <literal>InnoDB</literal> tables use a compact storage
+            format. Versions of MySQL prior to 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
             are created in the compact format
             (<literal>ROW_FORMAT=COMPACT</literal>). If you wish to
-            downgrade to older versions of MySQL/InnoDB, you can request
-            the old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
+            downgrade to older versions of MySQL, you can request the
+            old format with <literal>ROW_FORMAT=REDUNDANT</literal>.
           </para>
 
           <para>
@@ -6848,15 +6827,15 @@
 SELECT * FROM test WHERE last_name='Widenius';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' AND first_name='Michael';
+  WHERE last_name='Widenius' AND first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND (first_name='Michael' OR first_name='Monty');
+  WHERE last_name='Widenius'
+  AND (first_name='Michael' OR first_name='Monty');
 
 SELECT * FROM test
-    WHERE last_name='Widenius'
-    AND first_name &gt;='M' AND first_name &lt; 'N';
+  WHERE last_name='Widenius'
+  AND first_name &gt;='M' AND first_name &lt; 'N';
 </programlisting>
 
       <para>
@@ -6868,7 +6847,7 @@
 SELECT * FROM test WHERE first_name='Michael';
 
 SELECT * FROM test
-    WHERE last_name='Widenius' OR first_name='Michael';
+  WHERE last_name='Widenius' OR first_name='Michael';
 </programlisting>
 
       <para>
@@ -6967,7 +6946,7 @@
 
 <programlisting>
 SELECT MIN(<replaceable>key_part2</replaceable>),MAX(<replaceable>key_part2</replaceable>)
-    FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
+  FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>key_part1</replaceable>=10;
 </programlisting>
         </listitem>
 
@@ -6994,7 +6973,7 @@
 
 <programlisting>
 SELECT <replaceable>key_part3</replaceable> FROM <replaceable>tbl_name</replaceable> 
-    WHERE <replaceable>key_part1</replaceable>=1
+  WHERE <replaceable>key_part1</replaceable>=1
 </programlisting>
         </listitem>
 
@@ -7635,11 +7614,6 @@
 
         <title>&title-midpoint-insertion;</title>
 
-        <remark>
-          [JS] This continues to be the case for key management in 5.1,
-          right?
-        </remark>
-
         <para>
           By default, the key cache management system uses the LRU
           strategy for choosing key cache blocks to be evicted, but it

Modified: trunk/refman-5.1/porting.xml
===================================================================
--- trunk/refman-5.1/porting.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/porting.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -699,7 +699,7 @@
         happens, you should check all your tables with
         <command>myisamchk</command> (see
         <xref linkend="database-administration"/>), and test the queries
-        in the MySQL log files to see if one doesn't work. If you find
+        in the MySQL log files to see whether one fails. If you find
         such a query, try first upgrading to the newest MySQL version.
         If this doesn't help and you can't find anything in the
         <literal>mysql</literal> mail archive, you should report the bug

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/replication.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -2113,8 +2113,8 @@
 
           <listitem>
             <para>
-              Repeat the procedure later to see if you have better luck
-              next time.
+              Repeat the procedure later to see whether you have better
+              luck next time.
             </para>
           </listitem>
 
@@ -4042,8 +4042,8 @@
       <emphasis role="bold">A</emphasis>: With the currently available
       features, you would have to set up a master and a slave (or
       several slaves), and to write a script that monitors the master to
-      see if it is up. Then instruct your applications and the slaves to
-      change master in case of failure. Some suggestions:
+      check whether it is up. Then instruct your applications and the
+      slaves to change master in case of failure. Some suggestions:
     </para>
 
     <itemizedlist>

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -4638,10 +4638,10 @@
             and the client issuing the <literal>INSERT DELAYED</literal>
             statement can then continue. If the table is in use, the
             server holds the rows. When the table is free, the server
-            begins inserting rows, checking periodically to see if there
-            are any new read requests for the table. If there are, the
-            delayed row queue is suspended until the table becomes free
-            again. See <xref linkend="insert-delayed"/>.
+            begins inserting rows, checking periodically to see whether
+            there are any new read requests for the table. If there are,
+            the delayed row queue is suspended until the table becomes
+            free again. See <xref linkend="insert-delayed"/>.
           </para>
         </listitem>
 
@@ -7630,7 +7630,7 @@
 </programlisting>
 
         <para>
-          is equivalent to :
+          is equivalent to:
         </para>
 
 <programlisting>

Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-common/news-4.0.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -2203,8 +2203,8 @@
           matching rows, even an empty result set). The easiest way to
           check whether you are affected is to start
           <command>mysqld</command> with
-          <option>--skip-concurrent-insert</option> switch and see if it
-          helps.
+          <option>--skip-concurrent-insert</option> switch and see
+          whether it helps.
         </para>
       </listitem>
 

Modified: trunk/refman-common/news-connector-net.xml
===================================================================
--- trunk/refman-common/news-connector-net.xml	2006-01-16 17:48:07 UTC (rev 856)
+++ trunk/refman-common/news-connector-net.xml	2006-01-16 20:43:45 UTC (rev 857)
@@ -49,7 +49,7 @@
         <para>
           The parameter collection object's <literal>Add()</literal>
           method added parameters to the list without first checking to
-          see if the they already existed. Now it updates the value of
+          see whether they already existed. Now it updates the value of
           the existing parameter object if it exists. (Bug #13927)
         </para>
       </listitem>
@@ -1655,8 +1655,8 @@
 
       <listitem>
         <para>
-          ConnectionInternal is now using PING to see if the server is
-          alive
+          ConnectionInternal is now using PING to see whether the server
+          is alive
         </para>
       </listitem>
 

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