table of Contents
1. InnoDB several concepts index table
2. covering index and back to the table
3. paging query
4. The delay associated Optimization
EDITORIAL
The following are introduced in selected MySQL database and Innodb basis for the engine. Let's learn a few concepts indexes help us understand why accelerate query speed paging delay associated with optimization.
A, Innodb several concepts index table
InnoDB table is based on the establishment of the clustered index.
Generally divided into the main index and the ordinary index key index (secondary index), a clustered index is not the primary key index index type such individual, but a data storage. Popular for individual indexes are stored index information B + Tree , the clustered index is stored in the same configuration B + Tree and data lines, i.e. through the primary key index Tree B + structure establishment of data files ( the argument is that the online index and data are stored in the same file), so the clustered index is a data storage.
If you are not very familiar with the concept of the index, it is recommended to study access to relevant information, the index is a huge knowledge structure.
Innodb table to build the primary key index suffix .MYD table storage file, the general index drawn up B + Tree implemented and stored in a suffix .MYI document, a specific configuration is shown as below:
Selection of primary key index and the general index What it is not the same in the query?
For example the following statement:
· SELECT * from Table ID = WHERE. 5; ( ID green arrow key index based) as shown above retrieval process, according to the master key retrieved directly in the main index tree
· SELECT * from Table WHERE name = "Gates"; ( name of general index) red arrows shown above retrieval process, obtained according to an ordinary search of the general index tree index id is 5 , and then let the resulting id to the primary index tree retrieved results. In this process, the primary key index back to the process of the search tree, we called back to the table.
As can be seen from here, it requires multiple scans of the index tree based on a query of a non-primary key index. Therefore, we should try to use the primary key query in the application.
After explaining the process of indexing and retrieval ordinary primary key index, let's look at what is covered by the index.
Second, the coverage index and back to the table.
What is a " covering index " ?
Column of the query is covered by secondary index built without back to the table. It is explained by the vernacular, to check the data may be able to get directly from the index tree without having to look back to the table.
Note: Not all types of indexes can become a covering index. Covering index must store the index of the column, and the value of the hash index, spatial indexing and full-text indexes are not stored in the index column, so MySQL can only use B-Tree indexes do a covering index
In conjunction with the example above:
· SELECT ID from Table WHERE name = "Gates"; that is, a covering index.
Third, the paging query usage scenarios
Demand: information on the latest 7 -day orders and do pagination. Orders table the amount of data: 3000W .
Non-optimized SQL :
select * from t_trade_order
where create_time between '2019-10-17' and '2019-10-25'
limit 1000000, 10;
According to explain the results of the output shows that this is a slow query, the query does not allow such a slow business environment.
We all know that when doing pagination will be used Limit keywords to filter the data required, limit acceptance 1 one or a 2 parameters, the first parameter indicates the offset accept two parameters, which row to start fetching data, the second parameter indicates the number of lines to be fetched. If only one parameter corresponding to an offset of 0 . When the offset is large, such as limit 100000,10 take the first 100001-100010 records, MySQL will remove 100010 records then the front 100000 records discarded, this is a tremendous waste of performance.
Finally turn to the question, then we should be how to optimize it?
Fourth, the delay associated with optimization
"High Performance MySQL " In fact, the book also discusses the situation:
Associated delay optimization: By using the primary key index query coverage required to return, then to obtain data required according to the master key associated with the original table.
select * from t_trade_order t
inner join (
select id from t_trade_order
where create_time between '2019-10-17' and '2019-10-25'
limit 1000000, 10
) e
on t.id = e.id;
According to explain the analysis, query time is only 0.31 , query an order of magnitude faster than an ordinary paging.
Surely you would want to know why the delay associated contrast to the common paging query optimization can play such an effect?
This relates to the above stated two important concepts covered by the index and back to the table!
Let's look at these two statements of the implementation process is very clear.
Optimization ago:
select * from t_trade_order
where create_time between '2019-10-17' and '2019-10-25'
limit 1000000, 10;
( Create_time is set to be built when the general index table)
1. In create_time find the index tree create_time = '2019-10-17' records, to obtain its ID .
2. and then to the main index tree found for id record
3. The number is less than 10 , the update time, the loop of steps 1 , 2
4. 。。。
5. In create_time index tree to remove a value create_time = '2019-10-25' , the condition is not satisfied, the loop ends.
6. results before giving up one million rows, returns 10 rows
Obviously, ordinary paging query is passed by one of ordinary index id and then back to the table query, back to the table once every IO , resulting in considerable performance wasted.
Optimized
select * from t_trade_order t
inner join (
select id from t_trade_order
where create_time between '2019-10-17' and '2019-10-25'
limit 1000000, 10
) e
on t.id = e.id;
1. The use of a covering index, SELECT ID from the create_time t_trade_order WHERE BETWEEN '2019-10-17' and '2019-10-25' limit 1,000,000, 10 , the query result before giving one million rows, returns 10 rows , query the scope that match the query id
2 , back to the association table, based on the obtained id associated master index table, volume matching result. (Just return to the main index table once)
It can be seen, by using coverage index query primary key to return to the need, and then get the desired row based on the primary key associated with these original tables, this can reduce the MySQL number back to the table, but also to avoid the MySQL number of scanning lines that need to be dropped directly on the original table (actually a tree in the general index scan, much faster).
Articles I write to you, I want to understand the delay associated with optimizing a slight help.
