In actual project development, since we don't know what happened in the database during the actual query, how the database software scans the table and how to use the index, what we can perceive is only
When the SQL statement runs, the query is instantaneous when the data size is small. Therefore, performance issues are rarely considered when writing SQL statements. But when the scale of data increases, such as tens of millions or billions, we will
When we ran the same sql statement, we found that there was no result. Only at this time did we know that the size of the data had limited the speed of our query. Therefore, query optimization and indexing are also very important.
question:
When we can pre-estimate how many rows the query will involve, which indexes to use, and the running time before the query? The answer is yes, mysql provides the corresponding function and syntax to achieve this function.
analyze:
MySql provides EXPLAIN syntax for query analysis, just add an "EXPLAIN" before the SQL statement. For example, we want to analyze the following SQL statement:
explain select * from table where table.id = 1
After running the above sql statement, you will see the following header information:
table | type | possible_keys | key | key_len | ref | rows | Extra
Explanation of the EXPLAIN column
table shows which table the data in this row is about
type This is the important column showing what type of connection is used. The join types from best to worst are const, eq_reg, ref, range, indexhe, and ALL
Description: Explanation of different connection types (in order of efficiency)
The system: table has only one row: the system table. This is a special case of const connection types.
const : The maximum value of a record in the table that can match this query (the index can be a primary key or a unique index). Since there is only one row, this value is actually a constant, because MYSQL reads the value first and treats it as a constant.
eq_ref: In the connection, MYSQL reads a record from the table for the union of each record from the previous table when querying. It is used when the query uses the index as the primary key or all of the unique key.
ref: This join type only occurs when the query uses keys that are not unique or primary keys, or parts of these types (eg, using the leftmost prefix). For each row union of the previous table, all records will be read from the table. This type is heavily dependent on how many records are matched against the index - the fewer the better.
range: This join type returns the rows in a range using an index, as happens when using > or < to find something.
index: This join type performs a full scan of each record union in the preceding table (better than ALL because indexes are generally smaller than table data).
ALL: This join type performs a full scan of each preceding record union, which is generally bad and should be avoided as much as possible.
possible_keys shows the indexes that may be applied to this table. If empty, there are no possible indices. An appropriate statement can be selected from the WHERE statement for the relevant field
The index actually used by key. If NULL, no index is used. In rare cases, MYSQL will choose an index that is under-optimized. In this case, you can use USE INDEX(indexname) in the SELECT statement to force the use of an index or IGNORE INDEX(indexname) to force MySQL to ignore the index
The length of the index used by key_len. Shorter lengths are better without loss of accuracy
ref shows which column of the index is used, a constant if possible
rows The number of rows that MYSQL thinks must be checked to return the requested data
Extra Extra information on how MYSQL parses the query. will be discussed in table 4.3, but bad examples that can be seen here are Using temporary and Using filesort, meaning MYSQL cannot use indexes at all, and as a result retrieval will be slow
Description: The meaning of the description returned by the extra column
Distinct: Once mysql finds a row that matches the row union, no more searches.
Not exists : MySQL optimizes LEFT JOIN, once it finds a row that matches the LEFT JOIN criteria, it doesn't search anymore.
Range checked for each Record (index map: #): The ideal index was not found, so for each combination of rows from the preceding table, mysql checks which index is used and uses it to return rows from the table. This is one of the slowest connections using indexes.
Using filesort : When you see this, the query needs to be optimized. MySQL takes an extra step to discover how to order the returned rows. It sorts all rows based on the join type and the row pointers that store the sort key value and all rows matching the criteria.
Using index : Column data is returned from a table that only uses the information in the index without the actual read action, which occurs when all requested columns for the table are part of the same index.
Using temporary : When you see this, the query needs to be optimized. Here, mysql needs to create a temporary table to store the results, which usually happens with ORDER BY on different sets of columns, not GROUP BY.
Where used: A WHERE clause is used to limit which rows will be matched to the next table or returned to the user. This can happen if you don't want to return all the rows in the table, and the join type is ALL or index, or there is something wrong with the query.
Therefore, by understanding each result returned by the explain syntax, we can know the approximate running time of the query. If the index is not used in the query, or if there are too many rows to scan, then you can feel a significant delay. Therefore, it is necessary to change the query method or create an index. The explain syntax in mysql can help us rewrite the query, optimize the table structure and index settings, so as to maximize the query efficiency. Of course, when there is a large amount of data, the cost of establishing and maintaining an index is also very high, and it often takes a long time and a larger space. If an index is established on different column combinations, the space overhead will be greater. Therefore, the index is best set in the field that needs to be queried frequently.