List:Commits« Previous MessageNext Message »
From:paul Date:January 16 2006 2:43am
Subject:svn commit - mysqldoc@docsrva: r848 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-16 03:43:01 +0100 (Mon, 16 Jan 2006)
New Revision: 848

Log:
 r6240@frost:  paul | 2006-01-15 20:37:51 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/optimization.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml


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

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-4.1/optimization.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -152,23 +152,8 @@
 
       <para>
         To change the preceding behaviors, you can enable stricter data
-        handling by setting the server SQL mode appropriately.
-      </para>
-
-      <remark role="todo">
-        We should really drop this next paragraph. We get a lot of flack
-        over stuff like this, which is quite possibly justified...
-      </remark>
-
-      <para>
-        If you are using non-transactional tables, you should not use
-        MySQL to check column content. In general, the safest (and often
-        fastest) way is to let the application ensure that it passes
-        only legal values to the database.
-      </para>
-
-      <para>
-        For more information about data handling, see
+        handling by setting the server SQL mode appropriately. For more
+        information about data handling, see
         <xref linkend="constraints"/>,
         <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
@@ -779,18 +764,19 @@
         <literal>EXPLAIN</literal> syntax also was augmented to allow
         the <literal>EXTENDED</literal> keyword. When this keyword is
         used, <literal>EXPLAIN</literal> produces extra information that
-        can be viewed with <literal>SHOW WARNINGS</literal>. This
-        information displays how the optimizer qualifies table and
+        can be viewed by issuing a <literal>SHOW WARNINGS</literal>
+        statement following the <literal>EXPLAIN</literal> statement.
+        This information displays how the optimizer qualifies table and
         column names in the <literal>SELECT</literal> statement, what
-        the <literal>SELECT</literal> looks like after rewriting and
-        optimization rules have been applied, and possibly other notes
+        the <literal>SELECT</literal> looks like after the application
+        of rewriting and optimization rules, and possibly other notes
         about the optimization process.
       </para>
 
       <para>
         Each output row from <literal>EXPLAIN</literal> provides
-        information about one table, and each row consists of the
-        following columns:
+        information about one table, and each row contains the following
+        columns:
       </para>
 
       <remark role="todo">
@@ -818,97 +804,59 @@
 
           <para>
             The type of <literal>SELECT</literal>, which can be any of
-            the following:
+            those shown in the following table:
           </para>
 
-          <itemizedlist>
+          <informaltable>
+            <tgroup cols="2">
+              <colspec colwidth="25*"/>
+              <colspec colwidth="75*"/>
+              <tbody>
+                <row>
+                  <entry><literal>SIMPLE</literal></entry>
+                  <entry>Simple <literal>SELECT</literal> (not using <literal>UNION</literal> or
+                    subqueries)</entry>
+                </row>
+                <row>
+                  <entry><literal>PRIMARY</literal></entry>
+                  <entry>Outermost <literal>SELECT</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal>, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>UNION RESULT</literal></entry>
+                  <entry>Result of a <literal>UNION</literal>.</entry>
+                </row>
+                <row>
+                  <entry><literal>SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery</entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>DERIVED</literal></entry>
+                  <entry>Derived table <literal>SELECT</literal> (subquery in
+                    <literal>FROM</literal> clause)</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
 
-            <listitem>
-              <para>
-                <literal>SIMPLE</literal>
-              </para>
-
-              <para>
-                Simple <literal>SELECT</literal> (not using
-                <literal>UNION</literal> or subqueries)
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>PRIMARY</literal>
-              </para>
-
-              <para>
-                Outermost <literal>SELECT</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>, dependent on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION RESULT</literal>
-              </para>
-
-              <para>
-                Result of a <literal>UNION</literal>.
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery, dependent
-                on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DERIVED</literal>
-              </para>
-
-              <para>
-                Derived table <literal>SELECT</literal> (subquery in
-                <literal>FROM</literal> clause)
-              </para>
-            </listitem>
-
-          </itemizedlist>
+          <para>
+            <literal>DEPENDENT</literal> typically signifies the use of
+            a correlated subquery. See
+            <xref linkend="correlated-subqueries"/>.
+          </para>
         </listitem>
 
         <listitem>
@@ -979,7 +927,7 @@
               <para>
                 <literal>const</literal> is used when you compare all
                 parts of a <literal>PRIMARY KEY</literal> or
-                <literal>UNIQUE</literal> index with constant values. In
+                <literal>UNIQUE</literal> index to constant values. In
                 the following queries,
                 <replaceable>tbl_name</replaceable> can be used as a
                 <literal>const</literal> table:
@@ -1001,10 +949,10 @@
               <para>
                 One row is read from this table for each combination of
                 rows from the previous tables. Other than the
-                <literal>const</literal> types, this is the best
-                possible join type. It is used when all parts of an
-                index are used by the join and the index is a
-                <literal>PRIMARY KEY</literal> or
+                <literal>system</literal> and <literal>const</literal>
+                types, this is the best possible join type. It is used
+                when all parts of an index are used by the join and the
+                index is a <literal>PRIMARY KEY</literal> or
                 <literal>UNIQUE</literal> index.
               </para>
 
@@ -1013,12 +961,8 @@
                 columns that are compared using the <literal>=</literal>
                 operator. The comparison value can be a constant or an
                 expression that uses columns from tables that are read
-                before this table.
-              </para>
-
-              <para>
-                In the following examples, MySQL can use an
-                <literal>eq_ref</literal> join to process
+                before this table. In the following examples, MySQL can
+                use an <literal>eq_ref</literal> join to process
                 <replaceable>ref_table</replaceable>:
               </para>
 
@@ -1057,15 +1001,11 @@
               <para>
                 <literal>ref</literal> can be used for indexed columns
                 that are compared using the <literal>=</literal> or
-                <literal>&lt;=&gt;</literal> operator.
+                <literal>&lt;=&gt;</literal> operator. In the following
+                examples, MySQL can use a <literal>ref</literal> join to
+                process <replaceable>ref_table</replaceable>:
               </para>
 
-              <para>
-                In the following examples, MySQL can use a
-                <literal>ref</literal> join to process
-                <replaceable>ref_table</replaceable>:
-              </para>
-
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
 
@@ -1088,15 +1028,11 @@
                 the addition that MySQL does an extra search for rows
                 that contain <literal>NULL</literal> values. This join
                 type optimization was added for MySQL 4.1.1 and is used
-                mostly when resolving subqueries.
+                mostly when resolving subqueries. In the following
+                examples, MySQL can use a <literal>ref_or_null</literal>
+                join to process <replaceable>ref_table</replaceable>:
               </para>
 
-              <para>
-                In the following examples, MySQL can use a
-                <literal>ref_or_null</literal> join to process
-                <replaceable>ref_table</replaceable>:
-              </para>
-
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable>
 WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable> OR <replaceable>key_column</replaceable> IS NULL;
@@ -1153,15 +1089,15 @@
               <para>
                 Only rows that are in a given range are retrieved, using
                 an index to select the rows. The <literal>key</literal>
-                column indicates which index is used. The
-                <literal>key_len</literal> contains the longest key part
-                that was used. The <literal>ref</literal> column is
+                column in the output row indicates which index is used.
+                The <literal>key_len</literal> contains the longest key
+                part that was used. The <literal>ref</literal> column is
                 <literal>NULL</literal> for this type.
               </para>
 
               <para>
-                <literal>range</literal> can be used for when a key
-                column is compared to a constant using any of the
+                <literal>range</literal> can be used when a key column
+                is compared to a constant using any of the
                 <literal>=</literal>, <literal>&lt;&gt;</literal>,
                 <literal>&gt;</literal>, <literal>&gt;=</literal>,
                 <literal>&lt;</literal>, <literal>&lt;=</literal>,
@@ -1194,7 +1130,7 @@
               <para>
                 This join type is the same as <literal>ALL</literal>,
                 except that only the index tree is scanned. This usually
-                is faster than <literal>ALL</literal>, because the index
+                is faster than <literal>ALL</literal> because the index
                 file usually is smaller than the data file.
               </para>
 
@@ -1231,9 +1167,9 @@
 
           <para>
             The <literal>possible_keys</literal> column indicates which
-            indexes MySQL could use to find the rows in this table. Note
-            that this column is totally independent of the order of the
-            tables as displayed in the output from
+            indexes MySQL can choose from use to find the rows in this
+            table. Note that this column is totally independent of the
+            order of the tables as displayed in the output from
             <literal>EXPLAIN</literal>. That means that some of the keys
             in <literal>possible_keys</literal> might not be usable in
             practice with the generated table order.
@@ -1305,8 +1241,8 @@
 
           <para>
             The <literal>ref</literal> column shows which columns or
-            constants are used with the <literal>key</literal> to select
-            rows from the table.
+            constants are compared to the index named in the
+            <literal>key</literal> column to select rows from the table.
           </para>
         </listitem>
 
@@ -1333,8 +1269,8 @@
 
           <para>
             This column contains additional information about how MySQL
-            resolves the query. Here is an explanation of the different
-            text strings that can appear in this column:
+            resolves the query. Here is an explanation of the values
+            that can appear in this column:
           </para>
 
           <itemizedlist>
@@ -1345,8 +1281,9 @@
               </para>
 
               <para>
-                MySQL stops searching for more rows for the current row
-                combination after it has found the first matching row.
+                MySQL is looking for distinct values, so it stops
+                searching for more rows for the current row combination
+                after it has found the first matching row.
               </para>
             </listitem>
 
@@ -1360,14 +1297,10 @@
                 optimization on the query and does not examine more rows
                 in this table for the previous row combination after it
                 finds one row that matches the <literal>LEFT
-                JOIN</literal> criteria.
+                JOIN</literal> criteria. Here is an example of the type
+                of query that can be optimized this way:
               </para>
 
-              <para>
-                Here is an example of the type of query that can be
-                optimized this way:
-              </para>
-
 <programlisting>
 SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
   WHERE t2.id IS NULL;
@@ -1421,13 +1354,13 @@
               </para>
 
               <para>
-                MySQL needs to do an extra pass to find out how to
-                retrieve the rows in sorted order. The sort is done by
-                going through all rows according to the join type and
-                storing the sort key and pointer to the row for all rows
-                that match the <literal>WHERE</literal> clause. The keys
-                then are sorted and the rows are retrieved in sorted
-                order. See <xref linkend="order-by-optimization"/>.
+                MySQL must do an extra pass to find out how to retrieve
+                the rows in sorted order. The sort is done by going
+                through all rows according to the join type and storing
+                the sort key and pointer to the row for all rows that
+                match the <literal>WHERE</literal> clause. The keys then
+                are sorted and the rows are retrieved in sorted order.
+                See <xref linkend="order-by-optimization"/>.
               </para>
             </listitem>
 
@@ -1882,12 +1815,12 @@
       </indexterm>
 
       <para>
-        In general, when you want to make a slow <literal>SELECT ...
-        WHERE</literal> query faster, the first thing to check is
-        whether you can add an index. All references between 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
+        In general, when you want to make a slow <literal>SELECT
+        &hellip; WHERE</literal> query faster, the first thing to check
+        is whether you can add an index. All references between
+        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"/>.
       </para>
 
@@ -2303,7 +2236,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM t1 
+SELECT * FROM t1
     WHERE <replaceable>key_col</replaceable> &gt; 1 
     AND <replaceable>key_col</replaceable> &lt; 10;
 
@@ -2527,7 +2460,7 @@
 
             <para>
               Here, <replaceable>const1</replaceable>,
-              <replaceable>const2</replaceable>, ... are constants,
+              <replaceable>const2</replaceable>, &hellip; are constants,
               <replaceable>cmp</replaceable> is one of the
               <literal>=</literal>, <literal>&lt;=&gt;</literal>, or
               <literal>IS NULL</literal> comparison operators, and the
@@ -3132,8 +3065,8 @@
       </itemizedlist>
 
       <para>
-        With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
-        check whether MySQL can use indexes to resolve the query. It
+        With <literal>EXPLAIN SELECT &hellip; ORDER BY</literal>, you
+        can check whether MySQL can use indexes to resolve the query. It
         cannot if you see <literal>Using filesort</literal> in the
         <literal>Extra</literal> column. See <xref linkend="explain"/>.
       </para>
@@ -3336,10 +3269,11 @@
       <para>
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> queries as if you
-        specified <literal>ORDER BY <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> in the query as
-        well. If you include an <literal>ORDER BY</literal> clause
+        <replaceable>col2</replaceable>, &hellip;</literal> queries as
+        if you specified <literal>ORDER BY
+        <replaceable>col1</replaceable>,
+        <replaceable>col2</replaceable>, &hellip;</literal> in the query
+        as well. If you include an <literal>ORDER BY</literal> clause
         explicitly that contains the same column list, MySQL optimizes
         it away without any speed penalty, although the sorting still
         occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -4104,14 +4038,14 @@
 
         <listitem>
           <para>
-            Use <literal>ALTER TABLE ... ORDER BY
+            Use <literal>ALTER TABLE &hellip; ORDER BY
             <replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> if you
+            <replaceable>expr2</replaceable>, &hellip;</literal> if you
             mostly retrieve rows in
             <literal><replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> order. By
-            using this option after extensive changes to the table, you
-            may be able to get higher performance.
+            <replaceable>expr2</replaceable>, &hellip;</literal> order.
+            By using this option after extensive changes to the table,
+            you may be able to get higher performance.
           </para>
         </listitem>
 
@@ -5707,8 +5641,9 @@
 
       <para>
         MySQL 4.0 and later versions perform an additional
-        <literal>LIKE</literal> optimization. If you use <literal>...
-        LIKE '%<replaceable>string</replaceable>%'</literal> and
+        <literal>LIKE</literal> optimization. If you use
+        <literal>&hellip; LIKE
+        '%<replaceable>string</replaceable>%'</literal> and
         <replaceable>string</replaceable> is longer than three
         characters, MySQL uses the <firstterm>Turbo Boyer-Moore
         algorithm</firstterm> to initialize the pattern for the string
@@ -8271,7 +8206,7 @@
             </remark>
 
             <para>
-              If you rename a table with <literal>ALTER TABLE ...
+              If you rename a table with <literal>ALTER TABLE &hellip;
               RENAME</literal> and you do not move the table to another
               database, the symlinks in the database directory are
               renamed to the new names and the data file and index file
@@ -8285,8 +8220,8 @@
             </remark>
 
             <para>
-              If you use <literal>ALTER TABLE ... RENAME</literal> to
-              move a table to another database, the table is moved to
+              If you use <literal>ALTER TABLE &hellip; RENAME</literal>
+              to move a table to another database, the table is moved to
               the other database directory. The old symlinks and the
               files to which they pointed are deleted. In other words,
               the new table is not symlinked.

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.0/database-administration.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -6500,7 +6500,7 @@
               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 unindexed column, the query
+              <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

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -9524,8 +9524,8 @@
             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 command
-            <literal>SET engine-condition-pushdown=On;</literal>.
+            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.

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.0/optimization.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -152,23 +152,8 @@
 
       <para>
         To change the preceding behaviors, you can enable stricter data
-        handling by setting the server SQL mode appropriately.
-      </para>
-
-      <remark role="todo">
-        We should really drop this next paragraph. We get a lot of flack
-        over stuff like this, which is quite possibly justified...
-      </remark>
-
-      <para>
-        If you are using non-transactional tables, you should not use
-        MySQL to check column content. In general, the safest (and often
-        fastest) way is to let the application ensure that it passes
-        only legal values to the database.
-      </para>
-
-      <para>
-        For more information about data handling, see
+        handling by setting the server SQL mode appropriately. For more
+        information about data handling, see
         <xref linkend="constraints"/>,
         <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
@@ -772,18 +757,19 @@
       <para>
         When the <literal>EXTENDED</literal> keyword is used,
         <literal>EXPLAIN</literal> produces extra information that can
-        be viewed with <literal>SHOW WARNINGS</literal>. This
-        information displays how the optimizer qualifies table and
+        be viewed by issuing a <literal>SHOW WARNINGS</literal>
+        statement following the <literal>EXPLAIN</literal> statement.
+        This information displays how the optimizer qualifies table and
         column names in the <literal>SELECT</literal> statement, what
-        the <literal>SELECT</literal> looks like after rewriting and
-        optimization rules have been applied, and possibly other notes
+        the <literal>SELECT</literal> looks like after the application
+        of rewriting and optimization rules, and possibly other notes
         about the optimization process.
       </para>
 
       <para>
         Each output row from <literal>EXPLAIN</literal> provides
-        information about one table, and each row consists of the
-        following columns:
+        information about one table, and each row contains the following
+        columns:
       </para>
 
       <remark role="todo">
@@ -811,97 +797,59 @@
 
           <para>
             The type of <literal>SELECT</literal>, which can be any of
-            the following:
+            those shown in the following table:
           </para>
 
-          <itemizedlist>
+          <informaltable>
+            <tgroup cols="2">
+              <colspec colwidth="25*"/>
+              <colspec colwidth="75*"/>
+              <tbody>
+                <row>
+                  <entry><literal>SIMPLE</literal></entry>
+                  <entry>Simple <literal>SELECT</literal> (not using <literal>UNION</literal> or
+                    subqueries)</entry>
+                </row>
+                <row>
+                  <entry><literal>PRIMARY</literal></entry>
+                  <entry>Outermost <literal>SELECT</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal>, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>UNION RESULT</literal></entry>
+                  <entry>Result of a <literal>UNION</literal>.</entry>
+                </row>
+                <row>
+                  <entry><literal>SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery</entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>DERIVED</literal></entry>
+                  <entry>Derived table <literal>SELECT</literal> (subquery in
+                    <literal>FROM</literal> clause)</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
 
-            <listitem>
-              <para>
-                <literal>SIMPLE</literal>
-              </para>
-
-              <para>
-                Simple <literal>SELECT</literal> (not using
-                <literal>UNION</literal> or subqueries)
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>PRIMARY</literal>
-              </para>
-
-              <para>
-                Outermost <literal>SELECT</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>, dependent on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION RESULT</literal>
-              </para>
-
-              <para>
-                Result of a <literal>UNION</literal>.
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery, dependent
-                on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DERIVED</literal>
-              </para>
-
-              <para>
-                Derived table <literal>SELECT</literal> (subquery in
-                <literal>FROM</literal> clause)
-              </para>
-            </listitem>
-
-          </itemizedlist>
+          <para>
+            <literal>DEPENDENT</literal> typically signifies the use of
+            a correlated subquery. See
+            <xref linkend="correlated-subqueries"/>.
+          </para>
         </listitem>
 
         <listitem>
@@ -972,7 +920,7 @@
               <para>
                 <literal>const</literal> is used when you compare all
                 parts of a <literal>PRIMARY KEY</literal> or
-                <literal>UNIQUE</literal> index with constant values. In
+                <literal>UNIQUE</literal> index to constant values. In
                 the following queries,
                 <replaceable>tbl_name</replaceable> can be used as a
                 <literal>const</literal> table:
@@ -994,10 +942,10 @@
               <para>
                 One row is read from this table for each combination of
                 rows from the previous tables. Other than the
-                <literal>const</literal> types, this is the best
-                possible join type. It is used when all parts of an
-                index are used by the join and the index is a
-                <literal>PRIMARY KEY</literal> or
+                <literal>system</literal> and <literal>const</literal>
+                types, this is the best possible join type. It is used
+                when all parts of an index are used by the join and the
+                index is a <literal>PRIMARY KEY</literal> or
                 <literal>UNIQUE</literal> index.
               </para>
 
@@ -1006,12 +954,8 @@
                 columns that are compared using the <literal>=</literal>
                 operator. The comparison value can be a constant or an
                 expression that uses columns from tables that are read
-                before this table.
-              </para>
-
-              <para>
-                In the following examples, MySQL can use an
-                <literal>eq_ref</literal> join to process
+                before this table. In the following examples, MySQL can
+                use an <literal>eq_ref</literal> join to process
                 <replaceable>ref_table</replaceable>:
               </para>
 
@@ -1050,15 +994,11 @@
               <para>
                 <literal>ref</literal> can be used for indexed columns
                 that are compared using the <literal>=</literal> or
-                <literal>&lt;=&gt;</literal> operator.
+                <literal>&lt;=&gt;</literal> operator. In the following
+                examples, MySQL can use a <literal>ref</literal> join to
+                process <replaceable>ref_table</replaceable>:
               </para>
 
-              <para>
-                In the following examples, MySQL can use a
-                <literal>ref</literal> join to process
-                <replaceable>ref_table</replaceable>:
-              </para>
-
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
 
@@ -1081,11 +1021,7 @@
                 the addition that MySQL does an extra search for rows
                 that contain <literal>NULL</literal> values. This join
                 type optimization is used most often in resolving
-                subqueries.
-              </para>
-
-              <para>
-                In the following examples, MySQL can use a
+                subqueries. In the following examples, MySQL can use a
                 <literal>ref_or_null</literal> join to process
                 <replaceable>ref_table</replaceable>:
               </para>
@@ -1108,10 +1044,10 @@
               <para>
                 This join type indicates that the Index Merge
                 optimization is used. 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 the indexes used. For more
-                information, see
+                <literal>key</literal> column in the output row contains
+                a list of indexes used, and <literal>key_len</literal>
+                contains a list of the longest key parts for the indexes
+                used. For more information, see
                 <xref linkend="index-merge-optimization"/>.
               </para>
             </listitem>
@@ -1162,15 +1098,15 @@
               <para>
                 Only rows that are in a given range are retrieved, using
                 an index to select the rows. The <literal>key</literal>
-                column indicates which index is used. The
-                <literal>key_len</literal> contains the longest key part
-                that was used. The <literal>ref</literal> column is
+                column in the output row indicates which index is used.
+                The <literal>key_len</literal> contains the longest key
+                part that was used. The <literal>ref</literal> column is
                 <literal>NULL</literal> for this type.
               </para>
 
               <para>
-                <literal>range</literal> can be used for when a key
-                column is compared to a constant using any of the
+                <literal>range</literal> can be used when a key column
+                is compared to a constant using any of the
                 <literal>=</literal>, <literal>&lt;&gt;</literal>,
                 <literal>&gt;</literal>, <literal>&gt;=</literal>,
                 <literal>&lt;</literal>, <literal>&lt;=</literal>,
@@ -1203,7 +1139,7 @@
               <para>
                 This join type is the same as <literal>ALL</literal>,
                 except that only the index tree is scanned. This usually
-                is faster than <literal>ALL</literal>, because the index
+                is faster than <literal>ALL</literal> because the index
                 file usually is smaller than the data file.
               </para>
 
@@ -1240,9 +1176,9 @@
 
           <para>
             The <literal>possible_keys</literal> column indicates which
-            indexes MySQL could use to find the rows in this table. Note
-            that this column is totally independent of the order of the
-            tables as displayed in the output from
+            indexes MySQL can choose from use to find the rows in this
+            table. Note that this column is totally independent of the
+            order of the tables as displayed in the output from
             <literal>EXPLAIN</literal>. That means that some of the keys
             in <literal>possible_keys</literal> might not be usable in
             practice with the generated table order.
@@ -1314,8 +1250,8 @@
 
           <para>
             The <literal>ref</literal> column shows which columns or
-            constants are used with the <literal>key</literal> to select
-            rows from the table.
+            constants are compared to the index named in the
+            <literal>key</literal> column to select rows from the table.
           </para>
         </listitem>
 
@@ -1342,8 +1278,8 @@
 
           <para>
             This column contains additional information about how MySQL
-            resolves the query. Here is an explanation of the different
-            text strings that can appear in this column:
+            resolves the query. Here is an explanation of the values
+            that can appear in this column:
           </para>
 
           <itemizedlist>
@@ -1354,8 +1290,9 @@
               </para>
 
               <para>
-                MySQL stops searching for more rows for the current row
-                combination after it has found the first matching row.
+                MySQL is looking for distinct values, so it stops
+                searching for more rows for the current row combination
+                after it has found the first matching row.
               </para>
             </listitem>
 
@@ -1369,14 +1306,10 @@
                 optimization on the query and does not examine more rows
                 in this table for the previous row combination after it
                 finds one row that matches the <literal>LEFT
-                JOIN</literal> criteria.
+                JOIN</literal> criteria. Here is an example of the type
+                of query that can be optimized this way:
               </para>
 
-              <para>
-                Here is an example of the type of query that can be
-                optimized this way:
-              </para>
-
 <programlisting>
 SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
   WHERE t2.id IS NULL;
@@ -1413,17 +1346,14 @@
                 preceding tables, MySQL checks whether it is possible to
                 use a <literal>range</literal> or
                 <literal>index_merge</literal> access method to retrieve
-                rows. The applicability criteria are as described in
+                rows. This is not very fast, but is faster than
+                performing a join with no index at all. The
+                applicability criteria are as described in
                 <xref linkend="range-optimization"/>, and
                 <xref linkend="index-merge-optimization"/>, with the
                 exception that all column values for the preceding table
                 are known and considered to be constants.
               </para>
-
-              <para>
-                This is not very fast, but is faster than performing a
-                join with no index at all.
-              </para>
             </listitem>
 
             <listitem>
@@ -1432,13 +1362,13 @@
               </para>
 
               <para>
-                MySQL needs to do an extra pass to find out how to
-                retrieve the rows in sorted order. The sort is done by
-                going through all rows according to the join type and
-                storing the sort key and pointer to the row for all rows
-                that match the <literal>WHERE</literal> clause. The keys
-                then are sorted and the rows are retrieved in sorted
-                order. See <xref linkend="order-by-optimization"/>.
+                MySQL must do an extra pass to find out how to retrieve
+                the rows in sorted order. The sort is done by going
+                through all rows according to the join type and storing
+                the sort key and pointer to the row for all rows that
+                match the <literal>WHERE</literal> clause. The keys then
+                are sorted and the rows are retrieved in sorted order.
+                See <xref linkend="order-by-optimization"/>.
               </para>
             </listitem>
 
@@ -1496,9 +1426,9 @@
 
             <listitem>
               <para>
-                <literal>Using sort_union(...)</literal>, <literal>Using
-                union(...)</literal>, <literal>Using
-                intersect(...)</literal>
+                <literal>Using sort_union(&hellip;)</literal>,
+                <literal>Using union(&hellip;)</literal>, <literal>Using
+                intersect(&hellip;)</literal>
               </para>
 
               <para>
@@ -1530,25 +1460,21 @@
 
             <listitem>
               <para>
-                <emphasis role="bold">Note</emphasis>: This item applies
-                to <literal>NDB Cluster</literal> tables
-                <emphasis>only</emphasis>.
-              </para>
-
-              <para>
                 <literal>Using where with pushed condition</literal>
               </para>
 
               <para>
-                This means that MySQL Cluster is using
-                <firstterm>condition pushdown</firstterm> to improve the
-                efficiency of a direct comparison (<literal>=</literal>)
-                between a nonindexed column and a constant. In such
-                cases, the condition is <quote>pushed down</quote> to
-                the cluster's data nodes where it is evaluated in all
-                partitions simultaneously. This eliminates the need to
-                send non-matching rows over the network, and can speed
-                up such queries by a factor of 5 to 10 times over cases
+                This item applies to <literal>NDB Cluster</literal>
+                tables <emphasis>only</emphasis>. It means that MySQL
+                Cluster is using <firstterm>condition
+                pushdown</firstterm> to improve the efficiency of a
+                direct comparison (<literal>=</literal>) between a
+                non-indexed column and a constant. In such cases, the
+                condition is <quote>pushed down</quote> to the cluster's
+                data nodes where it is evaluated in all partitions
+                simultaneously. This eliminates the need to send
+                non-matching rows over the network, and can speed up
+                such queries by a factor of 5 to 10 times over cases
                 where condition pushdown could be but is not used.
               </para>
 
@@ -1581,11 +1507,17 @@
 
 <programlisting>
 mysql&gt; <userinput>EXPLAIN SELECT a,b FROM t1 WHERE b = 10;</userinput>
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
-| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                             |
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
-|  1 | SIMPLE      | t1    | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where with pushed condition |
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
+*************************** 1. row ***************************
+           id: 1
+  select_type: SIMPLE
+        table: t1
+         type: ALL
+possible_keys: NULL
+          key: NULL
+      key_len: NULL
+          ref: NULL
+         rows: 10
+        Extra: Using where with pushed condition
 </programlisting>
 
               <para>
@@ -1603,32 +1535,37 @@
                 pushdown is not applicable because an index exists on
                 column <literal>a</literal>. In the case of the second
                 query, a condition pushdown cannot be employed because
-                the comparison involving the unindexed column
+                the comparison involving the non-indexed column
                 <literal>b</literal> is an indirect one. (However, it
-                would apply, were you to reduce <literal>b + 1 =
+                would apply if you were to reduce <literal>b + 1 =
                 10</literal> to <literal>b = 9</literal> in the
                 <literal>WHERE</literal> clause.)
               </para>
 
               <para>
-                However, a condition pushdown may also be employed with
-                an indexed column when this column is compared with a
-                constant using a <literal>&gt;</literal> or
-                <literal>&lt;</literal> relation:
+                However, a condition pushdown may also be employed when
+                an indexed column column is compared with a constant
+                using a <literal>&gt;</literal> or
+                <literal>&lt;</literal> operator:
               </para>
 
 <programlisting>
 mysql&gt; <userinput>EXPLAIN SELECT a,b FROM t1 WHERE a&lt;2;</userinput>
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
-| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                             |
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
-|  1 | SIMPLE      | t1    | range | a             | a    | 5       | NULL |    2 | Using where with pushed condition |
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
+*************************** 1. row ***************************
+           id: 1
+  select_type: SIMPLE
+        table: t1
+         type: range
+possible_keys: a
+          key: a
+      key_len: 5
+          ref: NULL
+         rows: 2
+        Extra: Using where with pushed condition
 </programlisting>
 
               <para>
-                With regard to condition pushdown, you should keep in
-                mind that:
+                With regard to condition pushdown, keep in mind that:
               </para>
 
               <itemizedlist>
@@ -1645,18 +1582,15 @@
                 <listitem>
                   <para>
                     Condition pushdown capability is not used by
-                    default, and must be explicitly enabled. You can do
-                    this by executing the statement
+                    default. To enable it, you can start
+                    <command>mysqld</command> with the
+                    <option>--engine-condition-pushdown</option> option,
+                    or execute the following statement:
                   </para>
 
 <programlisting>
-SET engine-condition-pushdown=On;
+SET engine_condition_pushdown=On;
 </programlisting>
-
-                  <para>
-                    or by starting <command>mysqld</command> with
-                    <option>--engine-condition-pushdown</option>.
-                  </para>
                 </listitem>
 
               </itemizedlist>
@@ -2049,12 +1983,12 @@
       </indexterm>
 
       <para>
-        In general, when you want to make a slow <literal>SELECT ...
-        WHERE</literal> query faster, the first thing to check is
-        whether you can add an index. All references between 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
+        In general, when you want to make a slow <literal>SELECT
+        &hellip; WHERE</literal> query faster, the first thing to check
+        is whether you can add an index. All references between
+        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"/>.
       </para>
 
@@ -2470,7 +2404,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM t1 
+SELECT * FROM t1
     WHERE <replaceable>key_col</replaceable> &gt; 1 
     AND <replaceable>key_col</replaceable> &lt; 10;
 
@@ -2694,7 +2628,7 @@
 
             <para>
               Here, <replaceable>const1</replaceable>,
-              <replaceable>const2</replaceable>, ... are constants,
+              <replaceable>const2</replaceable>, &hellip; are constants,
               <replaceable>cmp</replaceable> is one of the
               <literal>=</literal>, <literal>&lt;=&gt;</literal>, or
               <literal>IS NULL</literal> comparison operators, and the
@@ -4552,8 +4486,8 @@
       </itemizedlist>
 
       <para>
-        With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
-        check whether MySQL can use indexes to resolve the query. It
+        With <literal>EXPLAIN SELECT &hellip; ORDER BY</literal>, you
+        can check whether MySQL can use indexes to resolve the query. It
         cannot if you see <literal>Using filesort</literal> in the
         <literal>Extra</literal> column. See <xref linkend="explain"/>.
       </para>
@@ -4670,10 +4604,11 @@
       <para>
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> queries as if you
-        specified <literal>ORDER BY <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> in the query as
-        well. If you include an <literal>ORDER BY</literal> clause
+        <replaceable>col2</replaceable>, &hellip;</literal> queries as
+        if you specified <literal>ORDER BY
+        <replaceable>col1</replaceable>,
+        <replaceable>col2</replaceable>, &hellip;</literal> in the query
+        as well. If you include an <literal>ORDER BY</literal> clause
         explicitly that contains the same column list, MySQL optimizes
         it away without any speed penalty, although the sorting still
         occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -5570,14 +5505,14 @@
 
         <listitem>
           <para>
-            Use <literal>ALTER TABLE ... ORDER BY
+            Use <literal>ALTER TABLE &hellip; ORDER BY
             <replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> if you
+            <replaceable>expr2</replaceable>, &hellip;</literal> if you
             mostly retrieve rows in
             <literal><replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> order. By
-            using this option after extensive changes to the table, you
-            may be able to get higher performance.
+            <replaceable>expr2</replaceable>, &hellip;</literal> order.
+            By using this option after extensive changes to the table,
+            you may be able to get higher performance.
           </para>
         </listitem>
 
@@ -7195,7 +7130,7 @@
       </para>
 
       <para>
-        If you use <literal>... LIKE
+        If you use <literal>&hellip; LIKE
         '%<replaceable>string</replaceable>%'</literal> and
         <replaceable>string</replaceable> is longer than three
         characters, MySQL uses the <firstterm>Turbo Boyer-Moore
@@ -9820,7 +9755,7 @@
             </remark>
 
             <para>
-              If you rename a table with <literal>ALTER TABLE ...
+              If you rename a table with <literal>ALTER TABLE &hellip;
               RENAME</literal> and you do not move the table to another
               database, the symlinks in the database directory are
               renamed to the new names and the data file and index file
@@ -9834,8 +9769,8 @@
             </remark>
 
             <para>
-              If you use <literal>ALTER TABLE ... RENAME</literal> to
-              move a table to another database, the table is moved to
+              If you use <literal>ALTER TABLE &hellip; RENAME</literal>
+              to move a table to another database, the table is moved to
               the other database directory. The old symlinks and the
               files to which they pointed are deleted. In other words,
               the new table is not symlinked.

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.1/database-administration.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -6469,7 +6469,7 @@
               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 unindexed column, the query
+              <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

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -11120,8 +11120,8 @@
             a speed up factor of 5-10. Please note that this feature is
             currently disabled by default (pending more thorough
             testing), but it should work in most cases. This feature can
-            be enabled through the use of the command <literal>SET
-            engine-condition-pushdown=On;</literal> command.
+            be enabled through the use of the <literal>SET
+            engine_condition_pushdown=On;</literal> statement.
             Alternatively, you can run <command>mysqld</command> with
             the this feature enabled by starting the MySQL server with
             the new <option>--engine-condition-pushdown</option> option

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
+++ trunk/refman-5.1/optimization.xml	2006-01-16 02:43:01 UTC (rev 848)
@@ -152,23 +152,8 @@
 
       <para>
         To change the preceding behaviors, you can enable stricter data
-        handling by setting the server SQL mode appropriately.
-      </para>
-
-      <remark role="todo">
-        We should really drop this next paragraph. We get a lot of flack
-        over stuff like this, which is quite possibly justified...
-      </remark>
-
-      <para>
-        If you are using non-transactional tables, you should not use
-        MySQL to check column content. In general, the safest (and often
-        fastest) way is to let the application ensure that it passes
-        only legal values to the database.
-      </para>
-
-      <para>
-        For more information about data handling, see
+        handling by setting the server SQL mode appropriately. For more
+        information about data handling, see
         <xref linkend="constraints"/>,
         <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
@@ -794,18 +779,19 @@
       <para>
         When the <literal>EXTENDED</literal> keyword is used,
         <literal>EXPLAIN</literal> produces extra information that can
-        be viewed with <literal>SHOW WARNINGS</literal>. This
-        information displays how the optimizer qualifies table and
+        be viewed by issuing a <literal>SHOW WARNINGS</literal>
+        statement following the <literal>EXPLAIN</literal> statement.
+        This information displays how the optimizer qualifies table and
         column names in the <literal>SELECT</literal> statement, what
-        the <literal>SELECT</literal> looks like after rewriting and
-        optimization rules have been applied, and possibly other notes
+        the <literal>SELECT</literal> looks like after the application
+        of rewriting and optimization rules, and possibly other notes
         about the optimization process.
       </para>
 
       <para>
         Each output row from <literal>EXPLAIN</literal> provides
-        information about one table, and each row consists of the
-        following columns:
+        information about one table, and each row contains the following
+        columns:
       </para>
 
       <remark role="todo">
@@ -833,97 +819,59 @@
 
           <para>
             The type of <literal>SELECT</literal>, which can be any of
-            the following:
+            those shown in the following table:
           </para>
 
-          <itemizedlist>
+          <informaltable>
+            <tgroup cols="2">
+              <colspec colwidth="25*"/>
+              <colspec colwidth="75*"/>
+              <tbody>
+                <row>
+                  <entry><literal>SIMPLE</literal></entry>
+                  <entry>Simple <literal>SELECT</literal> (not using <literal>UNION</literal> or
+                    subqueries)</entry>
+                </row>
+                <row>
+                  <entry><literal>PRIMARY</literal></entry>
+                  <entry>Outermost <literal>SELECT</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT UNION</literal></entry>
+                  <entry>Second or later <literal>SELECT</literal> statement in a
+                    <literal>UNION</literal>, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>UNION RESULT</literal></entry>
+                  <entry>Result of a <literal>UNION</literal>.</entry>
+                </row>
+                <row>
+                  <entry><literal>SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery</entry>
+                </row>
+                <row>
+                  <entry><literal>DEPENDENT SUBQUERY</literal></entry>
+                  <entry>First <literal>SELECT</literal> in subquery, dependent on outer query</entry>
+                </row>
+                <row>
+                  <entry><literal>DERIVED</literal></entry>
+                  <entry>Derived table <literal>SELECT</literal> (subquery in
+                    <literal>FROM</literal> clause)</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
 
-            <listitem>
-              <para>
-                <literal>SIMPLE</literal>
-              </para>
-
-              <para>
-                Simple <literal>SELECT</literal> (not using
-                <literal>UNION</literal> or subqueries)
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>PRIMARY</literal>
-              </para>
-
-              <para>
-                Outermost <literal>SELECT</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT UNION</literal>
-              </para>
-
-              <para>
-                Second or later <literal>SELECT</literal> statement in a
-                <literal>UNION</literal>, dependent on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>UNION RESULT</literal>
-              </para>
-
-              <para>
-                Result of a <literal>UNION</literal>.
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DEPENDENT SUBQUERY</literal>
-              </para>
-
-              <para>
-                First <literal>SELECT</literal> in subquery, dependent
-                on outer query
-              </para>
-            </listitem>
-
-            <listitem>
-              <para>
-                <literal>DERIVED</literal>
-              </para>
-
-              <para>
-                Derived table <literal>SELECT</literal> (subquery in
-                <literal>FROM</literal> clause)
-              </para>
-            </listitem>
-
-          </itemizedlist>
+          <para>
+            <literal>DEPENDENT</literal> typically signifies the use of
+            a correlated subquery. See
+            <xref linkend="correlated-subqueries"/>.
+          </para>
         </listitem>
 
         <listitem>
@@ -994,7 +942,7 @@
               <para>
                 <literal>const</literal> is used when you compare all
                 parts of a <literal>PRIMARY KEY</literal> or
-                <literal>UNIQUE</literal> index with constant values. In
+                <literal>UNIQUE</literal> index to constant values. In
                 the following queries,
                 <replaceable>tbl_name</replaceable> can be used as a
                 <literal>const</literal> table:
@@ -1016,10 +964,10 @@
               <para>
                 One row is read from this table for each combination of
                 rows from the previous tables. Other than the
-                <literal>const</literal> types, this is the best
-                possible join type. It is used when all parts of an
-                index are used by the join and the index is a
-                <literal>PRIMARY KEY</literal> or
+                <literal>system</literal> and <literal>const</literal>
+                types, this is the best possible join type. It is used
+                when all parts of an index are used by the join and the
+                index is a <literal>PRIMARY KEY</literal> or
                 <literal>UNIQUE</literal> index.
               </para>
 
@@ -1028,12 +976,8 @@
                 columns that are compared using the <literal>=</literal>
                 operator. The comparison value can be a constant or an
                 expression that uses columns from tables that are read
-                before this table.
-              </para>
-
-              <para>
-                In the following examples, MySQL can use an
-                <literal>eq_ref</literal> join to process
+                before this table. In the following examples, MySQL can
+                use an <literal>eq_ref</literal> join to process
                 <replaceable>ref_table</replaceable>:
               </para>
 
@@ -1072,15 +1016,11 @@
               <para>
                 <literal>ref</literal> can be used for indexed columns
                 that are compared using the <literal>=</literal> or
-                <literal>&lt;=&gt;</literal> operator.
+                <literal>&lt;=&gt;</literal> operator. In the following
+                examples, MySQL can use a <literal>ref</literal> join to
+                process <replaceable>ref_table</replaceable>:
               </para>
 
-              <para>
-                In the following examples, MySQL can use a
-                <literal>ref</literal> join to process
-                <replaceable>ref_table</replaceable>:
-              </para>
-
 <programlisting>
 SELECT * FROM <replaceable>ref_table</replaceable> WHERE <replaceable>key_column</replaceable>=<replaceable>expr</replaceable>;
 
@@ -1103,11 +1043,7 @@
                 the addition that MySQL does an extra search for rows
                 that contain <literal>NULL</literal> values. This join
                 type optimization is used most often in resolving
-                subqueries.
-              </para>
-
-              <para>
-                In the following examples, MySQL can use a
+                subqueries. In the following examples, MySQL can use a
                 <literal>ref_or_null</literal> join to process
                 <replaceable>ref_table</replaceable>:
               </para>
@@ -1130,10 +1066,10 @@
               <para>
                 This join type indicates that the Index Merge
                 optimization is used. 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 the indexes used. For more
-                information, see
+                <literal>key</literal> column in the output row contains
+                a list of indexes used, and <literal>key_len</literal>
+                contains a list of the longest key parts for the indexes
+                used. For more information, see
                 <xref linkend="index-merge-optimization"/>.
               </para>
             </listitem>
@@ -1184,15 +1120,15 @@
               <para>
                 Only rows that are in a given range are retrieved, using
                 an index to select the rows. The <literal>key</literal>
-                column indicates which index is used. The
-                <literal>key_len</literal> contains the longest key part
-                that was used. The <literal>ref</literal> column is
+                column in the output row indicates which index is used.
+                The <literal>key_len</literal> contains the longest key
+                part that was used. The <literal>ref</literal> column is
                 <literal>NULL</literal> for this type.
               </para>
 
               <para>
-                <literal>range</literal> can be used for when a key
-                column is compared to a constant using any of the
+                <literal>range</literal> can be used when a key column
+                is compared to a constant using any of the
                 <literal>=</literal>, <literal>&lt;&gt;</literal>,
                 <literal>&gt;</literal>, <literal>&gt;=</literal>,
                 <literal>&lt;</literal>, <literal>&lt;=</literal>,
@@ -1225,7 +1161,7 @@
               <para>
                 This join type is the same as <literal>ALL</literal>,
                 except that only the index tree is scanned. This usually
-                is faster than <literal>ALL</literal>, because the index
+                is faster than <literal>ALL</literal> because the index
                 file usually is smaller than the data file.
               </para>
 
@@ -1262,9 +1198,9 @@
 
           <para>
             The <literal>possible_keys</literal> column indicates which
-            indexes MySQL could use to find the rows in this table. Note
-            that this column is totally independent of the order of the
-            tables as displayed in the output from
+            indexes MySQL can choose from use to find the rows in this
+            table. Note that this column is totally independent of the
+            order of the tables as displayed in the output from
             <literal>EXPLAIN</literal>. That means that some of the keys
             in <literal>possible_keys</literal> might not be usable in
             practice with the generated table order.
@@ -1336,8 +1272,8 @@
 
           <para>
             The <literal>ref</literal> column shows which columns or
-            constants are used with the <literal>key</literal> to select
-            rows from the table.
+            constants are compared to the index named in the
+            <literal>key</literal> column to select rows from the table.
           </para>
         </listitem>
 
@@ -1364,8 +1300,8 @@
 
           <para>
             This column contains additional information about how MySQL
-            resolves the query. Here is an explanation of the different
-            text strings that can appear in this column:
+            resolves the query. Here is an explanation of the values
+            that can appear in this column:
           </para>
 
           <itemizedlist>
@@ -1376,8 +1312,9 @@
               </para>
 
               <para>
-                MySQL stops searching for more rows for the current row
-                combination after it has found the first matching row.
+                MySQL is looking for distinct values, so it stops
+                searching for more rows for the current row combination
+                after it has found the first matching row.
               </para>
             </listitem>
 
@@ -1391,14 +1328,10 @@
                 optimization on the query and does not examine more rows
                 in this table for the previous row combination after it
                 finds one row that matches the <literal>LEFT
-                JOIN</literal> criteria.
+                JOIN</literal> criteria. Here is an example of the type
+                of query that can be optimized this way:
               </para>
 
-              <para>
-                Here is an example of the type of query that can be
-                optimized this way:
-              </para>
-
 <programlisting>
 SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
   WHERE t2.id IS NULL;
@@ -1435,17 +1368,14 @@
                 preceding tables, MySQL checks whether it is possible to
                 use a <literal>range</literal> or
                 <literal>index_merge</literal> access method to retrieve
-                rows. The applicability criteria are as described in
+                rows. This is not very fast, but is faster than
+                performing a join with no index at all. The
+                applicability criteria are as described in
                 <xref linkend="range-optimization"/>, and
                 <xref linkend="index-merge-optimization"/>, with the
                 exception that all column values for the preceding table
                 are known and considered to be constants.
               </para>
-
-              <para>
-                This is not very fast, but is faster than performing a
-                join with no index at all.
-              </para>
             </listitem>
 
             <listitem>
@@ -1454,13 +1384,13 @@
               </para>
 
               <para>
-                MySQL needs to do an extra pass to find out how to
-                retrieve the rows in sorted order. The sort is done by
-                going through all rows according to the join type and
-                storing the sort key and pointer to the row for all rows
-                that match the <literal>WHERE</literal> clause. The keys
-                then are sorted and the rows are retrieved in sorted
-                order. See <xref linkend="order-by-optimization"/>.
+                MySQL must do an extra pass to find out how to retrieve
+                the rows in sorted order. The sort is done by going
+                through all rows according to the join type and storing
+                the sort key and pointer to the row for all rows that
+                match the <literal>WHERE</literal> clause. The keys then
+                are sorted and the rows are retrieved in sorted order.
+                See <xref linkend="order-by-optimization"/>.
               </para>
             </listitem>
 
@@ -1518,9 +1448,9 @@
 
             <listitem>
               <para>
-                <literal>Using sort_union(...)</literal>, <literal>Using
-                union(...)</literal>, <literal>Using
-                intersect(...)</literal>
+                <literal>Using sort_union(&hellip;)</literal>,
+                <literal>Using union(&hellip;)</literal>, <literal>Using
+                intersect(&hellip;)</literal>
               </para>
 
               <para>
@@ -1552,25 +1482,21 @@
 
             <listitem>
               <para>
-                <emphasis role="bold">Note</emphasis>: This item applies
-                to <literal>NDB Cluster</literal> tables
-                <emphasis>only</emphasis>.
-              </para>
-
-              <para>
                 <literal>Using where with pushed condition</literal>
               </para>
 
               <para>
-                This means that MySQL Cluster is using
-                <firstterm>condition pushdown</firstterm> to improve the
-                efficiency of a direct comparison (<literal>=</literal>)
-                between a nonindexed column and a constant. In such
-                cases, the condition is <quote>pushed down</quote> to
-                the cluster's data nodes where it is evaluated in all
-                partitions simultaneously. This eliminates the need to
-                send non-matching rows over the network, and can speed
-                up such queries by a factor of 5 to 10 times over cases
+                This item applies to <literal>NDB Cluster</literal>
+                tables <emphasis>only</emphasis>. It means that MySQL
+                Cluster is using <firstterm>condition
+                pushdown</firstterm> to improve the efficiency of a
+                direct comparison (<literal>=</literal>) between a
+                non-indexed column and a constant. In such cases, the
+                condition is <quote>pushed down</quote> to the cluster's
+                data nodes where it is evaluated in all partitions
+                simultaneously. This eliminates the need to send
+                non-matching rows over the network, and can speed up
+                such queries by a factor of 5 to 10 times over cases
                 where condition pushdown could be but is not used.
               </para>
 
@@ -1603,11 +1529,17 @@
 
 <programlisting>
 mysql&gt; <userinput>EXPLAIN SELECT a,b FROM t1 WHERE b = 10;</userinput>
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
-| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                             |
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
-|  1 | SIMPLE      | t1    | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where with pushed condition |
-+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------+
+*************************** 1. row ***************************
+           id: 1
+  select_type: SIMPLE
+        table: t1
+         type: ALL
+possible_keys: NULL
+          key: NULL
+      key_len: NULL
+          ref: NULL
+         rows: 10
+        Extra: Using where with pushed condition
 </programlisting>
 
               <para>
@@ -1625,32 +1557,37 @@
                 pushdown is not applicable because an index exists on
                 column <literal>a</literal>. In the case of the second
                 query, a condition pushdown cannot be employed because
-                the comparison involving the unindexed column
+                the comparison involving the non-indexed column
                 <literal>b</literal> is an indirect one. (However, it
-                would apply, were you to reduce <literal>b + 1 =
+                would apply if you were to reduce <literal>b + 1 =
                 10</literal> to <literal>b = 9</literal> in the
                 <literal>WHERE</literal> clause.)
               </para>
 
               <para>
-                However, a condition pushdown may also be employed with
-                an indexed column when this column is compared with a
-                constant using a <literal>&gt;</literal> or
-                <literal>&lt;</literal> relation:
+                However, a condition pushdown may also be employed when
+                an indexed column column is compared with a constant
+                using a <literal>&gt;</literal> or
+                <literal>&lt;</literal> operator:
               </para>
 
 <programlisting>
 mysql&gt; <userinput>EXPLAIN SELECT a,b FROM t1 WHERE a&lt;2;</userinput>
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
-| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                             |
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
-|  1 | SIMPLE      | t1    | range | a             | a    | 5       | NULL |    2 | Using where with pushed condition |
-+----+-------------+-------+-------+---------------+------+---------+------+------+-----------------------------------+
+*************************** 1. row ***************************
+           id: 1
+  select_type: SIMPLE
+        table: t1
+         type: range
+possible_keys: a
+          key: a
+      key_len: 5
+          ref: NULL
+         rows: 2
+        Extra: Using where with pushed condition
 </programlisting>
 
               <para>
-                With regard to condition pushdown, you should keep in
-                mind that:
+                With regard to condition pushdown, keep in mind that:
               </para>
 
               <itemizedlist>
@@ -1667,18 +1604,15 @@
                 <listitem>
                   <para>
                     Condition pushdown capability is not used by
-                    default, and must be explicitly enabled. You can do
-                    this by executing the statement
+                    default. To enable it, you can start
+                    <command>mysqld</command> with the
+                    <option>--engine-condition-pushdown</option> option,
+                    or execute the following statement:
                   </para>
 
 <programlisting>
-SET engine-condition-pushdown=On;
+SET engine_condition_pushdown=On;
 </programlisting>
-
-                  <para>
-                    or by starting <command>mysqld</command> with
-                    <option>--engine-condition-pushdown</option>.
-                  </para>
                 </listitem>
 
               </itemizedlist>
@@ -2064,12 +1998,12 @@
       </indexterm>
 
       <para>
-        In general, when you want to make a slow <literal>SELECT ...
-        WHERE</literal> query faster, the first thing to check is
-        whether you can add an index. All references between 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
+        In general, when you want to make a slow <literal>SELECT
+        &hellip; WHERE</literal> query faster, the first thing to check
+        is whether you can add an index. All references between
+        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"/>.
       </para>
 
@@ -2485,7 +2419,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM t1 
+SELECT * FROM t1
     WHERE <replaceable>key_col</replaceable> &gt; 1 
     AND <replaceable>key_col</replaceable> &lt; 10;
 
@@ -2709,7 +2643,7 @@
 
             <para>
               Here, <replaceable>const1</replaceable>,
-              <replaceable>const2</replaceable>, ... are constants,
+              <replaceable>const2</replaceable>, &hellip; are constants,
               <replaceable>cmp</replaceable> is one of the
               <literal>=</literal>, <literal>&lt;=&gt;</literal>, or
               <literal>IS NULL</literal> comparison operators, and the
@@ -4545,8 +4479,8 @@
       </itemizedlist>
 
       <para>
-        With <literal>EXPLAIN SELECT ... ORDER BY</literal>, you can
-        check whether MySQL can use indexes to resolve the query. It
+        With <literal>EXPLAIN SELECT &hellip; ORDER BY</literal>, you
+        can check whether MySQL can use indexes to resolve the query. It
         cannot if you see <literal>Using filesort</literal> in the
         <literal>Extra</literal> column. See <xref linkend="explain"/>.
       </para>
@@ -4663,10 +4597,11 @@
       <para>
         By default, MySQL sorts all <literal>GROUP BY
         <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> queries as if you
-        specified <literal>ORDER BY <replaceable>col1</replaceable>,
-        <replaceable>col2</replaceable>, ...</literal> in the query as
-        well. If you include an <literal>ORDER BY</literal> clause
+        <replaceable>col2</replaceable>, &hellip;</literal> queries as
+        if you specified <literal>ORDER BY
+        <replaceable>col1</replaceable>,
+        <replaceable>col2</replaceable>, &hellip;</literal> in the query
+        as well. If you include an <literal>ORDER BY</literal> clause
         explicitly that contains the same column list, MySQL optimizes
         it away without any speed penalty, although the sorting still
         occurs. If a query includes <literal>GROUP BY</literal> but you
@@ -5563,14 +5498,14 @@
 
         <listitem>
           <para>
-            Use <literal>ALTER TABLE ... ORDER BY
+            Use <literal>ALTER TABLE &hellip; ORDER BY
             <replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> if you
+            <replaceable>expr2</replaceable>, &hellip;</literal> if you
             mostly retrieve rows in
             <literal><replaceable>expr1</replaceable>,
-            <replaceable>expr2</replaceable>, ...</literal> order. By
-            using this option after extensive changes to the table, you
-            may be able to get higher performance.
+            <replaceable>expr2</replaceable>, &hellip;</literal> order.
+            By using this option after extensive changes to the table,
+            you may be able to get higher performance.
           </para>
         </listitem>
 
@@ -7187,7 +7122,7 @@
       </para>
 
       <para>
-        If you use <literal>... LIKE
+        If you use <literal>&hellip; LIKE
         '%<replaceable>string</replaceable>%'</literal> and
         <replaceable>string</replaceable> is longer than three
         characters, MySQL uses the <firstterm>Turbo Boyer-Moore
@@ -9945,7 +9880,7 @@
             </remark>
 
             <para>
-              If you rename a table with <literal>ALTER TABLE ...
+              If you rename a table with <literal>ALTER TABLE &hellip;
               RENAME</literal> and you do not move the table to another
               database, the symlinks in the database directory are
               renamed to the new names and the data file and index file
@@ -9959,8 +9894,8 @@
             </remark>
 
             <para>
-              If you use <literal>ALTER TABLE ... RENAME</literal> to
-              move a table to another database, the table is moved to
+              If you use <literal>ALTER TABLE &hellip; RENAME</literal>
+              to move a table to another database, the table is moved to
               the other database directory. The old symlinks and the
               files to which they pointed are deleted. In other words,
               the new table is not symlinked.

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