
| no matching row in     | The table was a const table (a table with only    |
| const table            | one possible matching row), but no row was found. |
+------------------------+---------------------------------------------------+
| No tables used         | The SELECT was a sub query that did not use any   |
|                        | tables. For example a there was no FROM clause    |
|                        | or a FROM DUAL clause.                            |
+------------------------+---------------------------------------------------+
| Not exists             | Stop searching after more row if we find one      |
|                        | single matching row. This optimization is used    |
|                        | with LEFT JOIN where one is explicitly searching  |
|                        | for rows that doesn't exists in the LEFT JOIN     |
|                        | TABLE. Example: SELECT * FROM t1 LEFT JOIN t2 on  |
|                        | (...) WHERE t2.not_null_column IS NULL.  As       |
|                        | t2.not_null_column can only be NULL if there was  |
|                        | no matching row for on condition, we can stop     |
|                        | searching if we find a single matching row.       |
+------------------------+---------------------------------------------------+
| Open_frm_only          | For information_schema tables.  Only the frm      |
|                        | (table definition file was opened) was opened     |
|                        | for each matching row.                            |
+------------------------+---------------------------------------------------+
| Open_full_table        | For information_schema tables. A full table open  |
|                        | for each matching row is done to retrieve the     |
|                        | requested information. (Slow)                     |
+------------------------+---------------------------------------------------+
| Open_trigger_only      | For information_schema tables. Only the trigger   |
|                        | file definition was opened for each matching row. |
+------------------------+---------------------------------------------------+
| Range checked for      | This only happens when there was no good default  |
| each record (index     | index to use but there may some index that could  |
| map: ...)              | be used when we can treat all columns from        |
|                        | previous table as constants.  For each row        |
|                        | combination the optimizer will decide which       |
|                        | index to use (if any) to fetch a row from this    |
|                        | table. This is not fast, but faster than a full   |
|                        | table scan that is the only other choice. The     |
|                        | index map is a bitmask that shows which index     |
|                        | are considered for each row condition.            |
+------------------------+---------------------------------------------------+
| Scanned 0/1/all        | For information_schema tables. Shows how many     |
| databases              | times we had to do a directory scan.              |
+------------------------+---------------------------------------------------+
| Select tables          | All tables in the join was optimized away. This   |
| optimized away         | happens when we are only using COUNT(*), MIN()    |
|                        | and MAX() functions in the SELECT and we where    |
|                        | able to replace all of these with constants.      |
+------------------------+---------------------------------------------------+
| Skip_open_table        | For information_schema tables. The queried table  |
|                        | didn't need to be opened.                         |
+------------------------+---------------------------------------------------+
| unique row not found   | The table was detected to be a const table (a     |
|                        | table with only one possible matching row)        |
|                        | during the early optimization phase, but no row   |
|                        | was found.                                        |
+------------------------+---------------------------------------------------+
| Using filesort         | Filesort is needed to resolve the query. This     |
|                        | means an extra phase where we first collect all   |
|                        | columns to sort, sort them with a disk based      |
|                        | merge sort and then use the sorted set to         |
|                        | retrieve the rows in sorted order. If the column  |
|                        | set is small, we store all the columns in the     |
|                        | sort file to not have to go to the database to    |
|                        | retrieve them again.                              |
+------------------------+---------------------------------------------------+
| Using index            | Only the index is used to retrieve the needed     |
|                        | information from the table. There is no need to   |
|                        | perform an extra seek to retrieve the actual      |
|                        | record.                                           |
+------------------------+---------------------------------------------------+