
| 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       | Like 'Using where' but the where condition is     |
| pushed condition       | pushed down to the table engine for internal      |
|                        | optimization at the row level.                    |
+------------------------+---------------------------------------------------+
| Using buffer           | The UPDATE statement will first buffer the rows,  |
|                        | and then run the updates, rather than do updates  |
|                        | on the fly. See Using Buffer UPDATE Algorithm     |
|                        | for a detailed explanation.                       |
+------------------------+---------------------------------------------------+

EXPLAIN EXTENDED
----------------

The EXTENDED keyword adds another column, filtered, to the output. This is a
percentage estimate of the table rows that will be filtered by the condition.

An EXPLAIN EXTENDED will always throw a warning, as it adds extra Message
information to a subsequent SHOW WARNINGS statement. This includes what the
SELECT query would look like after optimizing and rewriting rules are applied
and how the optimizer qualifies columns and tables.

Examples
--------

As synonym for DESCRIBE or SHOW COLUMNS FROM:

DESCRIBE city;
+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| Id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| Name       | char(35) | YES  |     | NULL    |                |
| Country    | char(3)  | NO   | UNI |         |                |
| District   | char(20) | YES  | MUL |         |                |
| Population | int(11)  | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

A simple set of examples to see how EXPLAIN can identify poor index usage:

CREATE TABLE IF NOT EXISTS `employees_example` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `first_name` varchar(30) NOT NULL,
 `last_name` varchar(40) NOT NULL,
 `position` varchar(25) NOT NULL,
 `home_address` varchar(50) NOT NULL,
 `home_phone` varchar(12) NOT NULL,
 `employee_code` varchar(25) NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `employee_code` (`employee_code`),
 KEY `first_name` (`first_name`,`last_name`)
) ENGINE=Aria;

INSERT INTO `employees_example` (`first_name`, `last_name`, `position`,
`home_address`, `home_phone`, `employee_code`)
 VALUES
 ('Mustapha', 'Mond', 'Chief Executive Officer', '692 Promiscuous Plaza',
'326-555-3492', 'MM1'),
 ('Henry', 'Foster', 'Store Manager', '314 Savage Circle', '326-555-3847',
'HF1'),
 ('Bernard', 'Marx', 'Cashier', '1240 Ambient Avenue', '326-555-8456', 'BM1'),