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 ***************************
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.
Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.
Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.