• table  (JSON name: table_name ) 

The name of the table to which the row of output refers. This can also be one of the following values: 

• <union M , N > : The row refers to the union of the rows with id  values of M  and N . 

• <derived N > : The row refers to the derived table result for the row with an id  value of N . A derived table may result, for example, from a subquery in the FROM  clause. 

• <subquery N > : The row refers to the result of a materialized subquery for the row with an id  value of N . See Section 8.2.2.2, “Optimizing Subqueries with Materialization” . 

• partitions  (JSON name: partitions ) 

The partitions from which records would be matched by the query. The value is NULL  for nonpartitioned tables. See Section 24.3.5, “Obtaining Information About Partitions” . 

• type  (JSON name: access_type ) 

The join type. For descriptions of the different types, see EXPLAIN  Join Types. 

• possible_keys  (JSON name: possible_keys ) 

The possible_keys  column indicates the indexes from which MySQL can choose to find the rows in this table. Note that this column is totally independent of the order of the tables as displayed in the output from EXPLAIN . That means that some of the keys in possible_keys  might not be usable in practice with the generated table order. 

If this column is NULL  (or undefined in JSON-formatted output), there are no relevant indexes. In this case, you may be able to improve the performance of your query by examining the WHERE  clause to check whether it refers to some column or columns that would be suitable for indexing. If so, create an appropriate index and check the query with EXPLAIN  again. See Section 13.1.9, “ALTER TABLE Statement” . 

To see what indexes a table has, use SHOW INDEX FROM tbl_name . 

• key  (JSON name: key ) 

The key  column indicates the key (index) that MySQL actually decided to use. If MySQL decides to use one of the possible_keys  indexes to look up rows, that index is listed as the key value. 

It is possible that key  may name an index that is not present in the possible_keys  value. This can happen if none of the possible_keys  indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index. That is, the named index covers the selected columns, so although it is not used to determine which rows to retrieve, an index scan is more efficient than a data row scan. 

For InnoDB , a secondary index might cover the selected columns even if the query also selects the primary key because InnoDB  stores the primary key value with each secondary index. If key  is NULL , MySQL found no index to use for executing the query more efficiently. 

To force MySQL to use or ignore an index listed in the possible_keys  column, use FORCE INDEX , USE INDEX , or IGNORE INDEX  in your query. See Section 8.9.4, “Index Hints” . 

For MyISAM  tables, running ANALYZE TABLE  helps the optimizer choose better indexes. For MyISAM tables, myisamchk --analyze  does the same. See Section 13.7.3.1, “ANALYZE TABLE Statement” , and Section 7.6, “MyISAM Table Maintenance and Crash Recovery” . 

