Oracle 5.0, Reference Manual

Page: 665 / 3232

EXPLAIN
Output Format
645
the variables from its outer context. For
UNCACHEABLE SUBQUERY
, the subquery is re-evaluated for
each row of the outer context.
Cacheability of subqueries differs from caching of query results in the query cache (which is
described in
Section 8.6.3.1, “How the Query Cache Operates” ). Subquery caching occurs during
query execution, whereas the query cache is used to store results only after query execution
finishes.
•
table
The name of the table to which the row of output refers. This can also be one of the following values:
•
<unionM,N>
: The row refers to the union of the rows with
id
values of
M
and
N
.
•
<derivedN>
: The row refers to the derived table result for the row with an
id
value of
N
. A
derived table may result, for example, from a subquery in the
FROM
clause.
•
type
The join type. For descriptions of the different types, see
EXPLAIN
Join Types .
•
possible_keys
The
possible_keys
column indicates which 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
EXPLAIN
. That means that some of the keys in
possible_keys
might not be usable in
practice with the generated table order.
If this column is
NULL
, there are no relevant indexes. In this case, you may be able to improve
the performance of your query by examining the
WHERE
clause to check whether it refers to some
column or columns that would be suitable for indexing. If so, create an appropriate index and check
the query with
EXPLAIN
again. See Section 13.1.4, “
ALTER TABLE
Syntax” .
To see what indexes a table has, use
SHOW INDEX FROM tbl_name
.
•
key
The
key
column indicates the key (index) that MySQL actually decided to use. If MySQL decides to
use one of the
possible_keys
indexes to look up rows, that index is listed as the key value.
It is possible that
key
will name an index that is not present in the
possible_keys
value. This
can happen if none of the
possible_keys
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 is not used to determine which rows to retrieve, an index scan is
more efficient than a data row scan.
For
InnoDB
, a secondary index might cover the selected columns even if the query also selects
the primary key because
InnoDB
stores the primary key value with each secondary index. If
key
is
NULL
, MySQL found no index to use for executing the query more efficiently.
To force MySQL to use or ignore an index listed in the
possible_keys
column, use
FORCE
INDEX
,
USE INDEX
, or
IGNORE INDEX
in your query. See Section 13.2.8.3, “Index Hint Syntax” .
For
MyISAM
,
NDB
, and
BDB
tables, running
ANALYZE TABLE
helps the optimizer choose better
indexes. For
MyISAM
tables,
myisamchk --analyze
does the same as
ANALYZE TABLE
. See
Section 7.6, “
MyISAM
Table Maintenance and Crash Recovery” .
•
key_len
The
key_len
column indicates the length of the key that MySQL decided to use. The length is
NULL
if the
key
column says
NULL
. Note that the value of
key_len
enables you to determine how many
parts of a multiple-part key MySQL actually uses.