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.                                           |
+------------------------+---------------------------------------------------+
| Using index condition  | Like 'Using where' but the where condition is     |
|                        | pushed down to the table engine for internal      |
|                        | optimization at the index level.                  |
+------------------------+---------------------------------------------------+
| Using index            | Like 'Using index condition' but in addition we   |
| condition(BKA)         | use batch key access to retrieve rows.            |
+------------------------+---------------------------------------------------+
| Using index for        | The index is being used to resolve a GROUP BY or  |
| group-by               | DISTINCT query. The rows are not read.  This is   |
|                        | very efficient if the table has a lot of          |
|                        | identical index entries as duplicates are         |
|                        | quickly jumped over.                              |
+------------------------+---------------------------------------------------+
| Using intersect(...)   | For index_merge joins. Shows which index are      |
|                        | part of the intersect.                            |
+------------------------+---------------------------------------------------+
| Using join buffer      | We store previous row combinations in a row       |
|                        | buffer to be able to match each row against all   |
|                        | of the rows combinations in the join buffer at    |
|                        | one go.                                           |
+------------------------+---------------------------------------------------+
| Using sort_union(...)  | For index_merge joins. Shows which index are      |
|                        | part of the union.                                |
+------------------------+---------------------------------------------------+
| Using temporary        | A temporary table is created to hold the result.  |
|                        | This typically happens if you are using GROUP     |
|                        | BY, DISTINCT or ORDER BY.                         |
+------------------------+---------------------------------------------------+
| Using where            | A WHERE expression (in additional to the          |
|                        | possible key lookup) is used to check if the row  |
|                        | should be accepted. If you don't have 'Using      |
|                        | where' together with a join type of ALL, you are  |
|                        | probably doing something wrong!                   |
+------------------------+---------------------------------------------------+
| Using where with       |A