Detailed explanation of MySQL covering index and index pushdown

Table of contents

1. Covering index

1.1. Overview

1.2. Clustered index, non-clustered index

1.3. Return table query

1.4. Covering index

2. Index push down


1. Covering index

1.1. Overview

Covering index is a method of using index to avoid "return to table query", thereby reducing query time consumption, so to talk about covering index, first we need to know what is "return to table query", "return to table query" is because of MySQL The index structure is determined by the phenomenon that the non-clustered index needs to find the clustered index to get data, so we need to understand the clustered index and non-clustered index in MySQL first.

The context of the article is to first talk about how the clustered index and non-clustered index bring about the problem of "returning the table query", and then how to use the covering index to solve this problem.

1.2. Clustered index, non-clustered index

For details about index foundation, B tree, B+ tree and other related details, please refer to the blogger's previous two articles:

Data structure (8) tree structure - B tree, B+ tree (including the complete tree building process)_b+ tree construction process__BugMan's blog-CSDN blog

Detailed explanation of MySQL index__BugMan's Blog - CSDN Blog

As we all know, there are two types of indexes in mysql:

  • clustered index
  • nonclustered index

Clustered index:

The leaf nodes of the clustered index hang on the data corresponding to all the indexes on a branch.

 MySQL will maintain a clustered index for each table by default. If the table has a primary key, then the clustered index is the primary key index. If there is no primary key, MySQL will still maintain a hidden clustered index for each table. In the InnoDB engine, this hidden clustered index is a 6-byte long ROWID, and each data row will have a hidden ROWID.

Non-clustered index:

The non-clustered index leaf nodes hang the index value and the value of the clustered index pointed to by the corresponding value, that is to say, the real data must be obtained from the clustered index.

1.3. Return table query

After talking about the non-clustered index above, we will definitely find the clustered index to get the data. In fact, the problem of "returning to the table query" has already been brought up. The so-called "returning to the table query" means that when we use the non-clustered index to query, we cannot The data is directly obtained, but the process of searching for data in the B+ tree of the clustered index is required through the value of the clustered index on the leaf node.

The problems caused by "back table query" are clear at a glance. The index is stored on the disk. After checking a B+ tree, you need to check the second B+ tree for traversal matching. Checking the second B+ tree brings additional IO is time-consuming. Disk IO is originally a mechanical action of disk rotation + magnetic head swinging up and down. This action is an extremely slow action in the computer's operating system and is extremely time-consuming.

1.4. Covering index

Covering index refers to select the specific field instead of select *, and build the composite index on the specific field to be queried, so that the data can be obtained on the non-clustered index, that is, the first B+ tree, so that there is no need to "return Table query".

Do an experiment:

I built a sys_user table, which immediately inserted 1 million pieces of data:

Then create an index on username:

create index index_username on sys_user(username);

A piece of data is queried without using a covering index:

explain select * from sys_user where username='test_852107';

Use a covering index to query one of the data:

explain select username from sys_user where username='test_852107';

 

2. Index push down

Index pushdown is a new feature introduced since MySQL 5.6. Its purpose is also to reduce "back-to-table queries", thereby improving the overall query efficiency.

Suppose there are three fields name, age, sex in the table,

It is no problem to write SQL like this, which perfectly satisfies the left prefix principle:

select * from tuser where name ='zou' and age=10 and sex=1;

But if the SQL is written like this, there will be problems, the index is broken, and the index value of sex is useless:

select * from tuser where name ='zou' and sex=1;

Before 5.6, if the index is broken, it will not go down. All matched data with name='zou' will be "returned to the table" one by one. This will undoubtedly cause a lot of meaningless additional IO overhead:

Pushing down the index means that after the index breaks and cannot continue, the table will not be returned immediately, but will be pushed down one step before continuing to compare other index fields, thereby reducing meaningless extra IO. Take the above table as an example, it will match name='zou' and find that the index is broken, and it will not return to the table immediately, but will continue to compare whether the sex is equal to 1:

 

Guess you like

Origin blog.csdn.net/Joker_ZJN/article/details/130631391