Author: paul
Date: 2007-04-19 15:49:11 +0200 (Thu, 19 Apr 2007)
New Revision: 5999
Log:
r23734@polar: paul | 2007-04-19 08:45:10 -0500
DISTINCT is related to GROUP BY, move the DISTINCT optimization
section near to the one for GROUP BY.
Modified:
trunk/refman-4.1/optimization.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.1/optimization.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:23662
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:19401
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:23734
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:19401
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2007-04-19 13:09:30 UTC (rev 5998)
+++ trunk/refman-4.1/optimization.xml 2007-04-19 13:49:11 UTC (rev 5999)
Changed blocks: 2, Lines Added: 71, Lines Deleted: 71; 5569 bytes
@@ -2798,77 +2798,6 @@
</section>
- <section id="distinct-optimization">
-
- <title><literal>DISTINCT</literal> Optimization</title>
-
- <indexterm>
- <primary>DISTINCT</primary>
- </indexterm>
-
- <indexterm>
- <primary>optimizing</primary>
- <secondary>DISTINCT</secondary>
- </indexterm>
-
- <para>
- <literal>DISTINCT</literal> combined with <literal>ORDER
- BY</literal> needs a temporary table in many cases.
- </para>
-
- <para>
- 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>
-
- <para>
- In most cases, a <literal>DISTINCT</literal> clause can be
- considered as a special case of <literal>GROUP BY</literal>. For
- example, the following two queries are equivalent:
- </para>
-
-<programlisting>
-SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
-
-SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
-</programlisting>
-
- <para>
- Due to this equivalence, the optimizations applicable to
- <literal>GROUP BY</literal> queries can be also applied to
- queries with a <literal>DISTINCT</literal> clause. Thus, for
- more details on the optimization possibilities for
- <literal>DISTINCT</literal> queries, see
- <xref linkend="group-by-optimization"/>.
- </para>
-
- <para>
- When combining <literal>LIMIT
- <replaceable>row_count</replaceable></literal> with
- <literal>DISTINCT</literal>, MySQL stops as soon as it finds
- <replaceable>row_count</replaceable> unique rows.
- </para>
-
- <para>
- If you do not use columns from all tables named in a query,
- MySQL stops scanning any unused tables as soon as it finds the
- first match. In the following case, assuming that
- <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 it finds the first row in
- <literal>t2</literal>:
- </para>
-
-<programlisting>
-SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
-</programlisting>
-
- </section>
-
<section id="left-join-optimization">
<title><literal>LEFT JOIN</literal> and <literal>RIGHT JOIN</literal>
@@ -3509,6 +3438,77 @@
</section>
+ <section id="distinct-optimization">
+
+ <title><literal>DISTINCT</literal> Optimization</title>
+
+ <indexterm>
+ <primary>DISTINCT</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>optimizing</primary>
+ <secondary>DISTINCT</secondary>
+ </indexterm>
+
+ <para>
+ <literal>DISTINCT</literal> combined with <literal>ORDER
+ BY</literal> needs a temporary table in many cases.
+ </para>
+
+ <para>
+ 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>
+
+ <para>
+ In most cases, a <literal>DISTINCT</literal> clause can be
+ considered as a special case of <literal>GROUP BY</literal>. For
+ example, the following two queries are equivalent:
+ </para>
+
+<programlisting>
+SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
+
+SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
+</programlisting>
+
+ <para>
+ Due to this equivalence, the optimizations applicable to
+ <literal>GROUP BY</literal> queries can be also applied to
+ queries with a <literal>DISTINCT</literal> clause. Thus, for
+ more details on the optimization possibilities for
+ <literal>DISTINCT</literal> queries, see
+ <xref linkend="group-by-optimization"/>.
+ </para>
+
+ <para>
+ When combining <literal>LIMIT
+ <replaceable>row_count</replaceable></literal> with
+ <literal>DISTINCT</literal>, MySQL stops as soon as it finds
+ <replaceable>row_count</replaceable> unique rows.
+ </para>
+
+ <para>
+ If you do not use columns from all tables named in a query,
+ MySQL stops scanning any unused tables as soon as it finds the
+ first match. In the following case, assuming that
+ <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 it finds the first row in
+ <literal>t2</literal>:
+ </para>
+
+<programlisting>
+SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
+</programlisting>
+
+ </section>
+
<section id="limit-optimization">
<title><literal>LIMIT</literal> Optimization</title>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2007-04-19 13:09:30 UTC (rev 5998)
+++ trunk/refman-5.0/optimization.xml 2007-04-19 13:49:11 UTC (rev 5999)
Changed blocks: 2, Lines Added: 71, Lines Deleted: 71; 5605 bytes
@@ -3323,77 +3323,6 @@
</section>
- <section id="distinct-optimization">
-
- <title><literal>DISTINCT</literal> Optimization</title>
-
- <indexterm>
- <primary>DISTINCT</primary>
- </indexterm>
-
- <indexterm>
- <primary>optimizing</primary>
- <secondary>DISTINCT</secondary>
- </indexterm>
-
- <para>
- <literal>DISTINCT</literal> combined with <literal>ORDER
- BY</literal> needs a temporary table in many cases.
- </para>
-
- <para>
- 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>
-
- <para>
- In most cases, a <literal>DISTINCT</literal> clause can be
- considered as a special case of <literal>GROUP BY</literal>. For
- example, the following two queries are equivalent:
- </para>
-
-<programlisting>
-SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
-
-SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
-</programlisting>
-
- <para>
- Due to this equivalence, the optimizations applicable to
- <literal>GROUP BY</literal> queries can be also applied to
- queries with a <literal>DISTINCT</literal> clause. Thus, for
- more details on the optimization possibilities for
- <literal>DISTINCT</literal> queries, see
- <xref linkend="group-by-optimization"/>.
- </para>
-
- <para>
- When combining <literal>LIMIT
- <replaceable>row_count</replaceable></literal> with
- <literal>DISTINCT</literal>, MySQL stops as soon as it finds
- <replaceable>row_count</replaceable> unique rows.
- </para>
-
- <para>
- If you do not use columns from all tables named in a query,
- MySQL stops scanning any unused tables as soon as it finds the
- first match. In the following case, assuming that
- <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 it finds the first row in
- <literal>t2</literal>:
- </para>
-
-<programlisting>
-SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
-</programlisting>
-
- </section>
-
<section id="left-join-optimization">
<title><literal>LEFT JOIN</literal> and <literal>RIGHT JOIN</literal>
@@ -5056,6 +4985,77 @@
</section>
+ <section id="distinct-optimization">
+
+ <title><literal>DISTINCT</literal> Optimization</title>
+
+ <indexterm>
+ <primary>DISTINCT</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>optimizing</primary>
+ <secondary>DISTINCT</secondary>
+ </indexterm>
+
+ <para>
+ <literal>DISTINCT</literal> combined with <literal>ORDER
+ BY</literal> needs a temporary table in many cases.
+ </para>
+
+ <para>
+ 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>
+
+ <para>
+ In most cases, a <literal>DISTINCT</literal> clause can be
+ considered as a special case of <literal>GROUP BY</literal>. For
+ example, the following two queries are equivalent:
+ </para>
+
+<programlisting>
+SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
+
+SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
+</programlisting>
+
+ <para>
+ Due to this equivalence, the optimizations applicable to
+ <literal>GROUP BY</literal> queries can be also applied to
+ queries with a <literal>DISTINCT</literal> clause. Thus, for
+ more details on the optimization possibilities for
+ <literal>DISTINCT</literal> queries, see
+ <xref linkend="group-by-optimization"/>.
+ </para>
+
+ <para>
+ When combining <literal>LIMIT
+ <replaceable>row_count</replaceable></literal> with
+ <literal>DISTINCT</literal>, MySQL stops as soon as it finds
+ <replaceable>row_count</replaceable> unique rows.
+ </para>
+
+ <para>
+ If you do not use columns from all tables named in a query,
+ MySQL stops scanning any unused tables as soon as it finds the
+ first match. In the following case, assuming that
+ <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 it finds the first row in
+ <literal>t2</literal>:
+ </para>
+
+<programlisting>
+SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
+</programlisting>
+
+ </section>
+
<section id="in-subquery-optimization">
<title>Optimizing <literal>IN</literal>/<literal>=ANY</literal> Subqueries</title>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2007-04-19 13:09:30 UTC (rev 5998)
+++ trunk/refman-5.1/optimization.xml 2007-04-19 13:49:11 UTC (rev 5999)
Changed blocks: 2, Lines Added: 71, Lines Deleted: 71; 5605 bytes
@@ -3370,77 +3370,6 @@
</section>
- <section id="distinct-optimization">
-
- <title><literal>DISTINCT</literal> Optimization</title>
-
- <indexterm>
- <primary>DISTINCT</primary>
- </indexterm>
-
- <indexterm>
- <primary>optimizing</primary>
- <secondary>DISTINCT</secondary>
- </indexterm>
-
- <para>
- <literal>DISTINCT</literal> combined with <literal>ORDER
- BY</literal> needs a temporary table in many cases.
- </para>
-
- <para>
- 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>
-
- <para>
- In most cases, a <literal>DISTINCT</literal> clause can be
- considered as a special case of <literal>GROUP BY</literal>. For
- example, the following two queries are equivalent:
- </para>
-
-<programlisting>
-SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
-
-SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
-</programlisting>
-
- <para>
- Due to this equivalence, the optimizations applicable to
- <literal>GROUP BY</literal> queries can be also applied to
- queries with a <literal>DISTINCT</literal> clause. Thus, for
- more details on the optimization possibilities for
- <literal>DISTINCT</literal> queries, see
- <xref linkend="group-by-optimization"/>.
- </para>
-
- <para>
- When combining <literal>LIMIT
- <replaceable>row_count</replaceable></literal> with
- <literal>DISTINCT</literal>, MySQL stops as soon as it finds
- <replaceable>row_count</replaceable> unique rows.
- </para>
-
- <para>
- If you do not use columns from all tables named in a query,
- MySQL stops scanning any unused tables as soon as it finds the
- first match. In the following case, assuming that
- <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 it finds the first row in
- <literal>t2</literal>:
- </para>
-
-<programlisting>
-SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
-</programlisting>
-
- </section>
-
<section id="left-join-optimization">
<title><literal>LEFT JOIN</literal> and <literal>RIGHT JOIN</literal>
@@ -5092,6 +5021,77 @@
</section>
+ <section id="distinct-optimization">
+
+ <title><literal>DISTINCT</literal> Optimization</title>
+
+ <indexterm>
+ <primary>DISTINCT</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>optimizing</primary>
+ <secondary>DISTINCT</secondary>
+ </indexterm>
+
+ <para>
+ <literal>DISTINCT</literal> combined with <literal>ORDER
+ BY</literal> needs a temporary table in many cases.
+ </para>
+
+ <para>
+ 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>
+
+ <para>
+ In most cases, a <literal>DISTINCT</literal> clause can be
+ considered as a special case of <literal>GROUP BY</literal>. For
+ example, the following two queries are equivalent:
+ </para>
+
+<programlisting>
+SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable>;
+
+SELECT c1, c2, c3 FROM t1 WHERE c1 > <replaceable>const</replaceable> GROUP BY c1, c2, c3;
+</programlisting>
+
+ <para>
+ Due to this equivalence, the optimizations applicable to
+ <literal>GROUP BY</literal> queries can be also applied to
+ queries with a <literal>DISTINCT</literal> clause. Thus, for
+ more details on the optimization possibilities for
+ <literal>DISTINCT</literal> queries, see
+ <xref linkend="group-by-optimization"/>.
+ </para>
+
+ <para>
+ When combining <literal>LIMIT
+ <replaceable>row_count</replaceable></literal> with
+ <literal>DISTINCT</literal>, MySQL stops as soon as it finds
+ <replaceable>row_count</replaceable> unique rows.
+ </para>
+
+ <para>
+ If you do not use columns from all tables named in a query,
+ MySQL stops scanning any unused tables as soon as it finds the
+ first match. In the following case, assuming that
+ <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 it finds the first row in
+ <literal>t2</literal>:
+ </para>
+
+<programlisting>
+SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;
+</programlisting>
+
+ </section>
+
<section id="in-subquery-optimization">
<title>Optimizing <literal>IN</literal>/<literal>=ANY</literal> Subqueries</title>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r5999 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 19 Apr |
