The most commonly used index usage rules (dry goods)
Article directory
I. Overview
In the previous articles, the principle of indexing and the structure of B+ tree were explained in detail. Today, based on this, let’s talk about some places where indexes are often used in normal development. In this way, everyone will pay attention to these points when writing SQL at ordinary times, thereby improving the performance of the query.
The screenshots of this article are used Explain. This is used to analyze the execution of SQL statements. Later articles will introduce them in detail. You don’t need to go into details here.
2. Common rules
1. Equivalent matching rules
This is the simplest, that is, the field used in the where condition is the field used when creating the index. When querying, it is directly searched in the secondary index, and then it will match the conditions that are exactly equal to the condition. that key. This is the easiest
2. Leftmost matching rule
Now there is an index like this
ADD INDEX `union_index`(`name`, `age`, `description`) USING BTREE;
When we use the where condition to query, if these three fields are used in the condition, then this joint index can be used. So what about the leftmost match? Let's see the following example:
Example 1:
WHERE description ='sadsad' and age = '32321'
Example 2:
WHERE `name` = 'xxxx' and age = 'xxxx' and description = 'xxxx'
Example three:
WHERE `name` = 'xxxx' and age = 'xxxx'
In the above three examples, only example 1 cannot use the index. Therefore, for the index union_index( name, age, description), if we want to use it, we need to write the conditions in the order of the index in the where statement.
Special case:
If you have all or part of the fields of the composite index in the where statement, but the order is not sorted according to the leftmost principle, at this time, if the order of the fields in the where condition can be adjusted to use the index, then MySQL will perform a query on the SQL. Optimized so that it can finally use the index
3. Leftmost prefix matching rule
This is easy to understand. Unlike the first full-value matching, as long as the prefix of the value meets the requirements, it does not need to be equal. That is to say 查找某字段以xxx开头的, the SQL statement is actually the following:
WHERE `name` like 'xxx%'
Because the B+ tree is arranged in order, it is completely possible to search according to the prefix, of course, the premise is that this field is an index field
4. Range matching rules
Compared with the name you can guess, this is actually the use of >or <to perform range queries. Like the following:
WHERE `name` > 'xxx111' and `name` < 'xxx999'
This search method is actually very simple, because the leaf nodes of the B+ tree species form a doubly linked list, and then the records in each leaf node form a singly linked list. When we perform a range query, we only need to The two conditions of the query find the "two ends" of the linked list, and then traverse the linked list to return the data back.
5. Leftmost matching rule + equal value matching rule + range matching rule
In fact, multiple rules are used at the same time. Not much nonsense. Let's look at the example directly:
data:
SQL statement:
WHERE `name` = 'AAAAC' AND age < 60 and age > 20
Execution effect:
The principle is very simple. In fact, it still conforms to the leftmost matching principle. Even if the order of namethe ageconditions is changed, it can still be used, because MySQL optimizes SQL so that it can meet the leftmost matching principle. With this premise, index can be used.
First, all matches are found based on the full value match of the first namefield, and then range matching is performed on these data.
3. Summary
The above explains 5 commonly used matching rules. In fact, there is no need to memorize them one by one. You only need to remember the common point of these rules, that is, you can use the B+ tree to search for data. Of course, the premise is that you have to B+ The tree is familiar enough. This is mentioned in my previous article. If you are given some conditions, if you can't use the B+ tree to find it, then MySQL will definitely not.
Familiar, this point has been mentioned in my previous article. If you are given some conditions, if you can't use B+ tree to find it, then MySQL will definitely not.
Personally, the above rules can actually be collectively referred to as " the way to find data with B+ tree ", because this is the essence
Well, the above is the whole content. If there are any questions or comments that need to be added, please point them out, and we can make progress together!