검색결과 리스트
EXPLAIN_Output에 해당되는 글 1건
- 2012.07.24 EXPLAIN Output Format
글
Column | Meaning |
id | The SELECT identifier |
select_type | The SELECT type |
table | The table for the output row |
type | The join type |
possible_keys | The possible indexes to choose |
key | The index actually chosen |
key_len | The length of the chosen key |
ref | The columns compared to the index |
rows | Estimate of rows to be examined |
filtered | Percentage of rows filtered by table condition |
Extra | Additional information |
The SELECT identifier. This is the sequential number of the SELECT within the query. The value can be NULL if the row refers to the union result of other rows. In this case, the table column shows a value like <unionM,N> to indicate that the row refers to the union of the rows with id values of M and N.
select_type
The type of SELECT, which can be any of those shown in the following table.
select_type Value | Meaning |
SIMPLE | Simple SELECT (not using UNION or subqueries) |
PRIMARY | Outermost SELECT |
UNION | Second or later SELECT statement in a UNION |
DEPENDENT UNION | Second or later SELECT statement in a UNION, dependent on outer query |
UNION RESULT | Result of a UNION. |
SUBQUERY | First SELECT in subquery |
DEPENDENT SUBQUERY | First SELECT in subquery, dependent on outer query |
DERIVED | Derived table SELECT (subquery in FROM clause) |
UNCACHEABLE SUBQUERY | A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query |
UNCACHEABLE UNION | The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY) |
DEPENDENT typically signifies the use of a correlated subquery. See Section 13.2.10.7, “Correlated Subqueries”.
DEPENDENT SUBQUERYevaluation differs from UNCACHEABLE SUBQUERY evaluation. For DEPENDENT SUBQUERY,the subquery is re-evaluated only once for each set of different values of thevariables from its outer context. For UNCACHEABLE SUBQUERY, the subquery is re-evaluated foreach row of the outer context.
Cacheability of subqueries differs fromcaching of query results in the query cache (which is described in Section 8.9.3.1,“How the Query Cache Operates”). Subquery cachingoccurs during query execution, whereas the query cache is used to store resultsonly after query execution finishes.
The name of the table to which the row of output refers. This can also be a value like <unionM,N> to indicate that the row refers to the union of the rows with id values of M and N, or a value like <derivedN> to indicate that 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.
type
The join type. For descriptions of the different types, see EXPLAIN Join Types.
possible_keys
The possible_keys column indicates which indexes MySQL can choose from use 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, 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.7, “ALTER TABLE Syntax”.
To see what indexes a table has, use SHOW INDEX FROM tbl_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 will 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 13.2.9.3, “Index Hint Syntax”.
For MyISAM and NDB tables, running ANALYZE TABLE helps the optimizer choose better indexes. For NDB tables, this also improves performance of distributed pushed-down joins. For MyISAM tables, myisamchk --analyze does the same as ANALYZE TABLE. See Section 7.6, “MyISAM Table Maintenance and Crash Recovery”.
key_len
The key_len column indicates the length of the key that MySQL decided to use. The length is NULL if the key column says NULL. Note that the value of key_len enables you to determine how many parts of a multiple-part key MySQL actually uses.
ref
The ref column shows which columns or constants are compared to the index named in the key column to select rows from the table.
rows
The rows column indicates the number of rows MySQL believes it must examine to execute the query.
For InnoDB tables, this number is an estimate, and may not always be exact.
filtered
The filtered column indicates an estimated percentage of table rows that will be filtered by the table condition. That is, rows shows the estimated number of rows examined and rows × filtered / 100 shows the number of rows that will be joined with previous tables. This column is displayed if you use EXPLAIN EXTENDED.
Extra
This column contains additional information about how MySQL resolves the query. For descriptions of the different values, see EXPLAIN Extra Information.
출처 : http://dev.mysql.com/doc/refman/5.5/en/explain-output.html
'-- MySQL' 카테고리의 다른 글
| CentOS6에 MySQL5.5.25a 설치 (0) | 2012.07.30 |
|---|---|
| mysql 테이블과 인덱스 설계 시 주의사항 13가지 (0) | 2012.07.24 |
| mysql버전 확인 (0) | 2012.07.24 |
| Show Processlist (like SP_WHO2) (0) | 2012.07.19 |
| WITH (NOLOCK) table hint equivalent for MySQL (0) | 2012.07.18 |
RECENT COMMENT