[MySQL] leftmost prefix optimization of MySQL index

1. Joint index

The index established on the primary key is called a clustered index, and the index established on ordinary fields is called a secondary index. The index created
by combining multiple ordinary fields is called a joint index, also known as a composite index.
When creating a joint index, you need to pay attention The order of multiple fields, because (a,b,c) and (b,a,c) will have different joint indexes when used. The use
of the joint index needs to follow the leftmost prefix matching principle, that is, follow the leftmost first method. index match

Example of federated index execution

Create a joint index of (a,b,c), and then give examples of all the situations that may be encountered, and write whether the index will be executed

Where statement whether the index is used
where a = 1Y, use to a
where a = 1 and b = 2 Y, used to a, b
where a = 1 and b = 2 and c = 3 Y, used to a, b, c
where a = 1 and b like ‘kk%’ and c = 3 Y, used to a, b, c
where a = 1 and b like ‘%kk’ and c = 3 Y, only use a
where a = 1 and b like ‘%kk%’ and c = 3 Y, only use a
where a = 1 and b like ‘k%kk%’ and c = 3 Y, used to a, b, c
where a = 1 and c = 3 A is used, but c is not allowed, and b is interrupted
where a =13 and b > 2 and c = 3 Use a and b, c cannot be used after the range, b is broken
where a is null and b is not null is null supports index but is not null does not support, so a can use index, but b may not be able to use index (8.0)
where b = 2 or where b = 3 and c = 4 or where c = 4 N
where a <> 1 cannot use the index where abs(a) =1 cannot use index
where b = 2 cannot use index where c = 3 cannot use index
where b = 2 and c = 3 cannot use index

Because of the query optimizer, the order of field a in the where clause does not matter

2. Index order by optimization

Sort in MySQL

There are two sorting methods in MySQL:

  • Using filesort: Through the table index or full table scan, read the data rows that meet the conditions, and then complete the sorting operation in the sort buffer sort buffer, all the sorting that does not directly return the sorting result through the index is called Using filesort
  • Using index: The ordered data is directly returned by sequential scanning of the ordered index. In this case, the Using index is used, no additional sorting is required, and the operation efficiency is high

Obviously, the Using index uses the index, which must have high performance, so we try to optimize the SQL to the Using index in actual use. Next, we will
test the use of the order by index

data preparation

For test data, the more the better. Prepare a table with a data volume of 2w
role table:

  • id: self-growth
  • role_name: random string, no repetition allowed
  • orders: 1-1000 any number
    insert image description here

no index

Here we are going to use the explain command, which is familiar to everyone

The explain command is mainly used to view the execution plan of SQL, which can simulate the optimizer to execute SQL query statements

Currently our role table has no index
insert image description here

Next, we will execute the following SQL statements to view the cases without and with indexes respectively

explain select * from role order by orders

insert image description here

At this point, you can see that because the conditional orders used in sorting do not use the index, the index will use the sorting buffer, that is, read the data, and then display it after sorting in the sorting buffer

indexed

At this time, we add an index to the role table

-- 给tb_user中的age和phone创建索引 
-- CREATE INDEZ 索引名 ON 表名(字段名...);
CREATE INDEX or_role ON role(orders,role_name);

insert image description here

Now we have created the required indexes and re-executed the previous SQL statement

explain select * from role order by orders, role_name

This time we can see that Using index appears in Extra, which means that we have used the index. At the same time, it should be noted that this time we used two sorting fields orders and role_name, which are the indexes we created before. As we all know, MySQL has its own execution optimizer. The position of the where clause index field is irrelevant, as long as it is used, is it the same for order by?

Where clause index field order is inconsistent

explain select * from role where orders = 500 and role_name like 'a%'

insert image description here

Let's just say, it doesn't matter if you don't know, there are pictures and the truth

The order by index field order is inconsistent

explain select * from role order by role_name,orders

Next, let's look at the case where the field order of the order by clause is inconsistent with the index order
insert image description here

As you can see, the situation of Using filesort still appeared in the end

Inconsistent ascending and descending order of index fields

explain select * from role order by orders asc, role_name desc

insert image description here

When we use order by, if we do not specify the order, the default is in ascending order, and the index is the same. The fields are in ascending order by default, but when we query, one ascending order and one descending order, then Using filesort will appear If we want to solve this problem, we can use the following SQL statement to specify the order of the index when generating the index

CREATE INDEX or_role ON role(orders asc,role_name desc);

3. Summary

When we use a joint index, we need to consider whether the leftmost prefix index is used in the where clause, and create the index reasonably. Because MySQL has an optimizer, we don’t need to consider the order of the fields in the where clause. When order by uses a joint index, it is necessary to consider whether the order by field is consistent with the index order, and whether the collation is consistent with the index.

Guess you like

Origin blog.csdn.net/u011397981/article/details/130678672