Oracle 5.0 Reference Manual page 669

No row satisfies the condition for a query such as
condition.
•
no matching row in const table
For a query with a join, there was an empty table or a table with no rows satisfying a unique index
condition.
•
No tables used
The query has no
FROM
•
Not exists
MySQL was able to do a
in this table for the previous row combination after it finds one row that matches the
criteria. Here is an example of the type of query that can be optimized this way:
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
Assume that
t2.id
in using the values of t1.id. If MySQL finds a matching row in t2, it knows that
t2
never be NULL, and does not scan through the rest of the rows in
In other words, for each row in t1, MySQL needs to do only a single lookup in t2, regardless of how
many rows actually match in t2.
•
Range checked for each record (index map: N)
MySQL found no good index to use, but found that some of indexes might be used after column
values from preceding tables are known. For each row combination in the preceding tables, MySQL
checks whether it is possible to use a
to retrieve 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
"Index Merge Optimization", with the exception that all column values for the preceding table are
known and considered to be constants.
Indexes are numbered beginning with 1, in the same order as shown by
The index map value
a value of (binary 11001) means that indexes 1, 4, and 5 will be considered.
0x19
•
Select tables optimized away
The query contained only aggregate functions
resolved using an index, or
determined that only one row should be returned.
•
unique row not found
For a query such as
index or
PRIMARY KEY
•
Using filesort
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
order. See Section 8.3.1.11,
•
Using index
Output Format
EXPLAIN
clause, or has a
FROM DUAL
optimization on the query and does not examine more rows
LEFT JOIN
is defined as NULL. In this case, MySQL scans
NOT
range
Section 8.3.1.3, "Range
is a bitmask value that indicates which indexes are candidates. For example,
N
[970]
COUNT(*)
tbl_name, no rows satisfy the condition for a
SELECT ... FROM
on the table.
clause. The keys then are sorted and the rows are retrieved in sorted
WHERE
"ORDER BY Optimization".
649
SELECT MIN(...) FROM ... WHERE
clause.
t2
[647] or
index_merge
Optimization", and
(MIN() [971],
MAX()
for MyISAM, and no
GROUP BY
LEFT JOIN
and looks up the rows
t1
t2.id
that have the same
id
[647] access method
Section 8.3.1.4,
for the table.
SHOW INDEX
[971]) that were all
clause. The optimizer
UNIQUE
can
value.