I. Introduction
Why is the retrieval process completely different for one more attribute?
select id,name from user where name='shenjian'
select id,name,sex from user where name='shenjian'2. What is back-to-table query?
This starts with InnoDB's index implementation. InnoDB has two types of indexes:
-
Clustered index (clustered index)
-
Ordinary index (secondary index)
What is the difference between InnoDB clustered index and ordinary index?
The leaf nodes of the InnoDB clustered index store row records. Therefore, InnoDB must have one and only one clustered index:
- If the table defines PK, PK is a clustered index;
- If the table does not define PK, the first not NULL unique column is a clustered index;
- Otherwise, InnoDB will create a hidden row-id as a clustered index;
So PK query is very fast, directly locate the row record.
The leaf nodes of InnoDB ordinary indexes store primary key values.
Note that instead of storing the row record header pointer, the index leaf node of MyISAM stores the record pointer.
For example, you might as well have a table:
user(id PK, name KEY, sex, flag);id is a clustered index, and name is a normal index.
There are four records in the table:
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
The two B+ tree indexes are as shown in the figure above:
1. ID is PK, clustered index, leaf nodes store row records;
2. The name is KEY, a common index, and the leaf node stores the PK value, that is, id;
Since the row record cannot be located directly from the ordinary index, what is the query process of the ordinary index?
Normally, you need to scan the index tree twice.
E.g:
select * from t where name='lisi';How is it implemented?
Such as the pink path, you need to scan the index tree twice:
- First locate the primary key value id=5 through the ordinary index;
- Locate the row record through the clustered index;
This is the so-called back-to-table query , which first locates the primary key value, and then locates the row record. Its performance is lower than scanning the index tree.
Three, what is index coverage
On the MySQL official website, a similar statement appears in the explain query plan optimization chapter, that is, when the Extra field of the output result of the explain is Using index, index coverage can be triggered.
Whether it is the official SQL-Server website or the official MySQL website, it is expressed: only one index tree can obtain all the column data required by SQL, no need to return to the table, faster.
Fourth, how to achieve index coverage?
The common method is to create the field to be queried into the joint index.
The first SQL statement:
select id,name from user where name='shenjian';It can hit the name index, the index leaf node stores the primary key id, and the id and name can be obtained through the index tree of the name, without returning to the table, conforming to the index coverage, and high efficiency.
The second SQL statement:
select id,name,sex from user where name='shenjian';The name index can be hit, and the index leaf node stores the primary key id, but the sex field must be retrieved from the table query. If the index coverage is not met, you need to scan the clustered index through the id value to obtain the sex field again, which will reduce the efficiency.
It is different if you upgrade the (name) single-column index to the joint index (name, sex).
can be seen:
select id,name from user where name='shenjian';
select id,name,sex from user where name='shenjian';Both can hit index coverage without returning to the table.
5. Which scenarios can use index coverage to optimize SQL?
Scenario 1: full table count query optimization
The original table is:
user(PK id, name, sex)；direct:
select count(name) from user;Cannot use index coverage.
Add index:
alter table user add key(name);You can use index coverage to improve efficiency.
Scenario 2: Column query back to table optimization
select id,name,sex from user where name='shenjian';This example will not go into details. Upgrade a single-column index (name) to a joint index (name, sex) to avoid returning to the table.
Scenario 3: Paging query
select id,name,sex from user order by name limit 500,100;Upgrade a single-column index (name) to a joint index (name, sex) to avoid returning to the table.
InnoDB clustered index ordinary index , back to the table , index coverage .