Author: paul
Date: 2006-11-03 00:37:12 +0100 (Fri, 03 Nov 2006)
New Revision: 3834
Log:
r11590@frost: paul | 2006-11-02 17:35:49 -0600
EXPLAIN: describe now the keys value can name an index not listed
in the possible_keys value. (Bug#18639)
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:15175
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:11508
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:11301
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:15175
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:11590
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:11301
Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml 2006-11-02 19:51:47 UTC (rev 3833)
+++ trunk/refman-4.1/optimization.xml 2006-11-02 23:37:12 UTC (rev 3834)
Changed blocks: 1, Lines Added: 29, Lines Deleted: 3; 2143 bytes
@@ -1217,9 +1217,35 @@
<para>
The <literal>key</literal> column indicates the key (index)
- that MySQL actually decided to use. The key is
- <literal>NULL</literal> if no index was chosen. To force
- MySQL to use or ignore an index listed in the
+ that MySQL actually decided to use. If MySQL decides to use
+ one of the <literal>possible_keys</literal> indexes to look
+ up rows, that index is listed as the key value.
+ </para>
+
+ <para>
+ If is possible that <literal>key</literal> will name an
+ index that is not present in the
+ <literal>possible_keys</literal> value. This can happen if
+ none of the <literal>possible_keys</literal> indexes are
+ suitable for looking up rows, but all the columns selected
+ by the query are columns of some other index. That is, the
+ named index covers the selected columns, so although it does
+ not act to retrieve the selected columns, an index scan is
+ more effecient than a data row scan.
+ </para>
+
+ <para>
+ For <literal>InnoDB</literal>, a secondary index might cover
+ the selected columns even if the query also selects the
+ primary key because <literal>InnoDB</literal> stores the
+ primary key value with each secondary index. If
+ <literal>key</literal> is <literal>NULL</literal>, MySQL
+ found no index to use for executing the query more
+ efficiently.
+ </para>
+
+ <para>
+ To force MySQL to use or ignore an index listed in the
<literal>possible_keys</literal> column, use <literal>FORCE
INDEX</literal>, <literal>USE INDEX</literal>, or
<literal>IGNORE INDEX</literal> in your query. See
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-11-02 19:51:47 UTC (rev 3833)
+++ trunk/refman-5.0/optimization.xml 2006-11-02 23:37:12 UTC (rev 3834)
Changed blocks: 1, Lines Added: 29, Lines Deleted: 3; 2143 bytes
@@ -1226,9 +1226,35 @@
<para>
The <literal>key</literal> column indicates the key (index)
- that MySQL actually decided to use. The key is
- <literal>NULL</literal> if no index was chosen. To force
- MySQL to use or ignore an index listed in the
+ that MySQL actually decided to use. If MySQL decides to use
+ one of the <literal>possible_keys</literal> indexes to look
+ up rows, that index is listed as the key value.
+ </para>
+
+ <para>
+ If is possible that <literal>key</literal> will name an
+ index that is not present in the
+ <literal>possible_keys</literal> value. This can happen if
+ none of the <literal>possible_keys</literal> indexes are
+ suitable for looking up rows, but all the columns selected
+ by the query are columns of some other index. That is, the
+ named index covers the selected columns, so although it does
+ not act to retrieve the selected columns, an index scan is
+ more effecient than a data row scan.
+ </para>
+
+ <para>
+ For <literal>InnoDB</literal>, a secondary index might cover
+ the selected columns even if the query also selects the
+ primary key because <literal>InnoDB</literal> stores the
+ primary key value with each secondary index. If
+ <literal>key</literal> is <literal>NULL</literal>, MySQL
+ found no index to use for executing the query more
+ efficiently.
+ </para>
+
+ <para>
+ To force MySQL to use or ignore an index listed in the
<literal>possible_keys</literal> column, use <literal>FORCE
INDEX</literal>, <literal>USE INDEX</literal>, or
<literal>IGNORE INDEX</literal> in your query. See
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-11-02 19:51:47 UTC (rev 3833)
+++ trunk/refman-5.1/optimization.xml 2006-11-02 23:37:12 UTC (rev 3834)
Changed blocks: 1, Lines Added: 29, Lines Deleted: 3; 2143 bytes
@@ -1266,9 +1266,35 @@
<para>
The <literal>key</literal> column indicates the key (index)
- that MySQL actually decided to use. The key is
- <literal>NULL</literal> if no index was chosen. To force
- MySQL to use or ignore an index listed in the
+ that MySQL actually decided to use. If MySQL decides to use
+ one of the <literal>possible_keys</literal> indexes to look
+ up rows, that index is listed as the key value.
+ </para>
+
+ <para>
+ If is possible that <literal>key</literal> will name an
+ index that is not present in the
+ <literal>possible_keys</literal> value. This can happen if
+ none of the <literal>possible_keys</literal> indexes are
+ suitable for looking up rows, but all the columns selected
+ by the query are columns of some other index. That is, the
+ named index covers the selected columns, so although it does
+ not act to retrieve the selected columns, an index scan is
+ more effecient than a data row scan.
+ </para>
+
+ <para>
+ For <literal>InnoDB</literal>, a secondary index might cover
+ the selected columns even if the query also selects the
+ primary key because <literal>InnoDB</literal> stores the
+ primary key value with each secondary index. If
+ <literal>key</literal> is <literal>NULL</literal>, MySQL
+ found no index to use for executing the query more
+ efficiently.
+ </para>
+
+ <para>
+ To force MySQL to use or ignore an index listed in the
<literal>possible_keys</literal> column, use <literal>FORCE
INDEX</literal>, <literal>USE INDEX</literal>, or
<literal>IGNORE INDEX</literal> in your query. See
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3834 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 3 Nov |
