Get technical dry goods and industry information for the first time!
Don't wave, wretched development. A large wave of Redis interview questions is coming
Do you know all the MySQL interview questions that BAT must ask?
How to learn the Web protocol by capturing the actual packet?
MySQL's High Concurrency Processing Technology MVCC
Teach you to build a classic MySQL master-slave replication architecture
You may have never heard of the term return form, but you must have used it in your actual work. If you haven't heard of back to the table, then I believe that no matter how much knowledge of SQL optimization you look at, it is still on the surface. Even if you have read my previous article "Please don't ask me about MySQL performance optimization!" ".
Let's take a look at what is back to the table?
In layman's terms, if the indexed column is in the column that select needs to obtain (because the index in mysql is sorted according to the value of the index column, so there are some values in the column in the index node) or according to an index query You can get records without returning to the table. If there are a large number of non-indexed columns in the columns that select needs to obtain, the index needs to find the corresponding column information in the table, which is called returning to the table.
According to this concept, when you use Explain to execute a query plan, when using index, using where, using index condition, etc. appear in Extra in the result, you think that the filter condition is used, the index is used, and the SQL optimization is not bad. This is actually a wrong understanding.
Because, using the index does not mean that the query is optimal. As can be seen from using index condition, using index & using where, etc., this SQL statement is actually returned to the table.
Sometimes, after checking the Explain execution plan, you find that the index is obviously gone. Why is it still slow? There may be back to the table. Below we use an example to illustrate what is back to the table. First create a table, the sql statement is as follows:
create table xttblog(
id int primary key,
k int not null,
name varchar(16),
index (k)
)engine = InnoDB;
Then, we execute the following SQL statement and insert a few pieces of test data.
Suppose, now we want to query the data with id 2. Then execute select * from xttblog where ID = 2; This SQL statement does not need to return to the table. The reason is that according to the query mode of the primary key, only the B+ tree of ID needs to be searched. The primary key is unique, and based on this unique index, MySQL can determine the record to be searched.
But when we use the k index to query k = 2 records, we need to use the back table. select * from xttblog where k = 2; The reason is that in the ordinary index query method of k, you need to search the k index tree first, and then get the value of the primary key ID to 1, and then search the ID index tree again. Although the index is used in this process, in fact, two index queries are performed at the bottom layer. This process is called returning to the table.
In other words, queries based on non-primary key indexes need to scan one more index tree. Therefore, we should try to use primary key queries in our applications.
The amount of data in the table here is relatively small. If the amount of data is large, you can clearly see the time taken for the two queries. Obviously, using the primary key query is more efficient.
I rarely see the above mentioned in the SQL optimization rules! Hope to help everyone!