B+ tree index use (9) grouping, back to table, overlay index (21)

In the last article, we talked about index sorting and sorting considerations , Don't use complex functions for sorting , When searching the range , The left column has indexing effect , The following columns have no , Unless you specify a specific value ,like Fuzzy query time , Don't use... In front %,asc desc Don't mix . The reason why index sorting is fast , because b+ The two-way linked list and one-way linked list data structures in the tree are originally sorted by index from small to large , So just take out the data directly , There is no need to sort in disk and memory .

B+ Tree index uses (8) Sorting use and precautions （ twenty )

For grouping

Sometimes we group some of the same data ：SELECT name, birthday, phone, COUNT(*) FROM person_info GROUP BY name, birthday, phone;

According to the first name Sort groups , all name Divide the same into groups .2） Again name The same value record continues to press birthday grouping , It seems that there are small groups in the big group .3） Press phone Divide into smaller groups . If there is no index , These need to be implemented in memory .

The price of returning the watch

It keeps saying back to the table , I haven't introduced it in detail , When we use select * from where person_info where name > ‘Anny’ and name <’barlow’; Query steps , First find the column in the leaf node of the column name>anny Primary key of , Query all data through the primary key back table query cluster index , Because we select * , All data is stored in the leaf node of the cluster index .

There are two key points in this process , The order I/O And random I/O：

First by column name Sort , therefore ’Anny’ and ’barlow’ These are because of the column b+ The trees have been sorted by them , So they are connected , In sequence I/O, High query efficiency , Then get their primary key id.

Use primary key id Query clustered index b+ Trees , By this time id Not connected , So it's random I/O, Efficiency ratio sequence I/O A lot lower .

So two indexes will be used , The order of secondary index I/O, It's a lot more efficient , Random clustering index I/O It's a lot less efficient . So if there is too much primary key data in the back table , Percent 80 The above needs to be reported , It's not as good as directly clustering index full table scan query .

Let's recall that ,mysql Client first through tcp/ip Access server , Then whether the cache exists , non-existent , decode sql, after mysql Query optimizer , Finally, go directly to the storage engine .

When do we use full table scanning , When to use secondary index + How about the clustering index method of the back table ？ This is mysterious mysql What the query optimizer needs to do , The query optimizer will make statistics on the data first , Then based on these data , To determine whether it is a full table scan or a secondary index + Back to the table , If there is less data in the back table , Use secondary index + Back to the table , such as SELECT * FROM person_info ORDER BY name, birthday, phone LIMIT 10; I've added one here limit10, So there is not much data in the query back table , Will use secondary index + Return form . If so SELECT * FROM person_info ORDER BY name, birthday, phone, It will scan the whole table .

Index overlay

With our idx_name_birthday_phone Union index as an example , When the column we query has only these three indexes ,SELECT name, birthday, phone FROM person_info ORDER BY name, birthday, phone; If you look at the previous article carefully, you will know , Joint indexing b+ What is stored in the leaf node of the tree ? yes name,birthday,phone And the primary key , At this time, the value of the query has been indexed from the secondary index b+ The cotyledon of the tree is queried , So there is no need to use the primary key cluster index to go to another b+ Tree back table , So even when we need to query non indexed data of other columns , It is not encouraged to use * Go to query .