MySQL's EXPLAIN is of course incomparable to ORACLE's, but we can also get a lot of useful information from the results it outputs.
In general, we only need to focus on a few columns in the result:
| column name | Remark |
|---|---|
| type | This query table join type, from here you can see the approximate efficiency of this query |
| key | The final selected index, if there is no index, the query efficiency is usually very poor |
| key_len | For the actual length of the index used for result filtering in this query, see another share ( FAQ Series - Interpretation of key_len in EXPLAIN Execution Plan ) |
| rows | Estimated number of records to be scanned, the smaller the number of records expected to be scanned, the better |
| Extra | Additional information, mainly to confirm whether there are two situations of Using filesort and Using temporary |
First, let's take a look at the results of type , and what they mean:
| Types of | Remark |
|---|---|
| ALL | The worst way to do a full table scan |
| index | Execute full index scan , and you can complete the result scan through the index and directly fetch the desired result data from the index, that is, you can avoid returning to the table , which is slightly better than ALL, because the index file is usually smaller than the entire data. |
| range | Use index for range query, slightly better than index |
| index_subquery | Indexes can be used in subqueries |
| unique_subquery | Unique index can be used in subquery, which is more efficient than index_subquery |
| index_merge | You can use the index merge feature to use multiple indexes to improve query efficiency |
| ref_or_null | The table join type is ref, but the index column being scanned may contain NULL values |
| fulltext | Full Text Search |
| ref | Index-based equivalence query, or equijoin between tables |
| eq_ref | When the table is joined, the scan is completed based on the primary key or non-NULL unique index, which is slightly better than ref |
| const | Query based on the unique value of the primary key or unique index, return at most one result, slightly better than eq_ref |
| system | The query object table has only one row of data, which is the best case |
In the above cases, the worst to the best is from the top to the next .
Let's take a look at several situations that need to be noticed in the Extra column:
| keywords | Remark |
|---|---|
| Using filesort | Will use external sorting instead of sorting the results according to the index order, sort from memory when there is less data, otherwise need to complete the sorting on disk, the cost is very high, you need to add a suitable index |
| Using temporary | A temporary table needs to be created to store the results. This usually happens when GROUP BY is performed on a column without an index, or the columns in the ORDER BY are not all in the index, and an appropriate index needs to be added. |
| Using index | Indicates that MySQL uses a covering index to avoid full table scans and does not need to search for data in the table twice, which is one of the better results. Be careful not to confuse the index type in type |
| Using where | Usually, a full table/full index scan is performed and then the WHERE clause is used to complete the result filtering, and an appropriate index needs to be added. |
| Impossible WHERE | The result of the judgment on the Where clause is always false and no data can be selected, such as where 1=0, no need to pay too much attention |
| Select tables optimized away | When using some aggregate functions to access a field with an index, the optimizer will directly locate the required data row through the index to complete the entire query, such as MIN()\MAX(), which is also one of the better results. one |
Besides, 5.6 began to support the optimizer trace function. It seems that the execution plan is gradually aligning with ORACLE :)