When EXPLAIN can be misleading
One think I can see with people using EXPLAIN is trusting it too much, ie assuming if number of rows is reported by EXPLAIN is large query must be inefficient. It may not be the case.
The question is not only about stats which may be wrong and which is why you may want to profile your queries if you have any hesitations in EXPLAIN accuracy.
The other problem however is EXPLAIN does not take LIMIT into account while estimating number of rows. Basically it gives you the estimates of producing whole result set while it may stop much faster in case LIMIT is used.
Take a look at this simple example:
-
mysql> EXPLAIN SELECT * FROM rnd ORDER BY r DESC LIMIT 1 \G
-
*************************** 1. row ***************************
-
id: 1
-
select_type: SIMPLE
-
TABLE: rnd
-
type: INDEX
-
possible_keys: NULL
-
KEY: r
-
key_len: 4
-
ref: NULL
-
rows: 49280
-
Extra: USING INDEX
-
1 row IN SET (0.00 sec)
This EXPLAIN estimates there would be almost 50.000 of rows scanned while really there would be only 1. Same applies to full table scans with limit.
The other little annoyance is - MySQL will report these queries to slow query log if --log-queries-not-using-indexes is enabled which may flood it quite badly. Too bad --min-examined-row-limit is not yet implemented 
EXPLAIN would also return misleading number of rows for queries of the type:
SELECT ... FROM TBL WHERE KEY_PART1=CONST ORDER BY KEY_PART2 LIMIT N
In this case it would not be considered full table scan and reported to slow query log however.
del.icio.us
digg1 Comment
[...] Original post by peter and software by Elliott Back 12:46 pm [...]
Pingback :: November 15, 2006 @ 12:42 am