[MySQL]-depth interviews necessary --MySQL Index Tuning combat

table of Contents

1. Create a table test (test table)

2, create an index

3, ordinary interrogated

4, order by check on the status

5, group by query case

6, other queries situation

7. Conclusions

Supplements: in optimization and exsits


1. Create a test table (test table)

drop table if exists test; 

create table test( 
	id int primary key auto_increment, 
	c1 varchar(10), 
	c2 varchar(10), 
	c3 varchar(10), 
	c4 varchar(10), 
	c5 varchar(10) 
) ENGINE=INNODB default CHARSET=utf8;
insert into test(c1,c2,c3,c4,c5) values('a1','a2','a3','a4','a5');
insert into test(c1,c2,c3,c4,c5) values('b1','b2','b3','b4','b5');
insert into test(c1,c2,c3,c4,c5) values('c1','c2','c3','c4','c5');
insert into test(c1,c2,c3,c4,c5) values('d1','d2','d3','d4','d5');
insert into test(c1,c2,c3,c4,c5) values('e1','e2','e3','e4','e5');

 

2, create an index

 

 

The following analysis of the use of the index

3, ordinary interrogated

Case 1

analysis:

① order to create a composite index of c1, c2, c3, c4.

② explain the four sets of results are performed as: type = ref, key_len = 132, ref = const, const, const, const.

Conclusion: performing constant equivalent query time, change the order of the index column does not change explain the results of , because the underlying mysql optimizer will optimize, but it is recommended to write sql statement in accordance with the order of the index column. Finally, a not think the order does not use the index because MySQL will optimize the bottom, although not in line with the principle of the most left-prefix, but will look at where the query conditions change, and it is consistent index order, eventually allowed to use the index. However, this optimization is only in the implementation of equivalent constant queries only .

 

Case 2

 

analysis:

When there is scope, type = range, key_len = 99, than not to increase the scope key_len = 66, instructions for use on the index, but the contrast in the results Case1, indicating the index fails on c4.

Conclusion: on the right range index column failure , but the scope of the current position ( C3 ) of the index is valid , provable from key_len = 99.

 

Case 2.1

analysis:

Explain the results of the above comparison, key_len = 132 uses four indices described, because the bottom of this optimization mysql sql statement will be optimized: failure right of the range index column (c4 have no right of a column index), Note that the order of the index ( c1, c2, c3, c4), it is not the right c4 index column failure occurs, and therefore to spend all four indices.

Conclusion: The right of the range index column failure is in order : c1, c2, c3, c4 , c3 if there is range, c4 failure; if c4 has a range, there is no failure of the index column, which will use the full index.

 

Case 2.2

analysis:

If you are using at the range of c1, then type = ALL, key = Null, index failure, a full table scan, where contrary to the best left-prefix rule, the lead brother is dead, because c1 is mainly used for range rather than querying.

Solution using covering indexes , index fields will overwrite MySQL query field will continue to use the index.

Conclusion: In the best left-prefix rule, if the leftmost in the forefront (lead brother) index fails , then the back of the indexes are invalid .

 

4, order by check on the status

Case 3

analysis:

Using the best left-prefix rule: middle brother can not be broken, and therefore uses c1 and c2 index (look) , from key_len = 66 ( The reason here is 66, see [MySQL] Explain Detailed index optimization and real ), ref = const, const, c3 index columns used in the sorting process is not used in the query process, so explain the display did not use an index on c3.

 

Case 3.1

analysis:

From the results explain the point of view: key_len = 66, ref = const , const, in order to find the only index used c1 and c2, c3 index for sorting .

 

Case 3.2

analysis:

From the results explain the point of view: key_len = 66, ref = const , const, c1 and c2 query uses the index, because the sort used c4, skipped c3, appeared in the Using filesort . Description not use the index at the time of the c4 sort of, because the front also said, in the middle of c3 not use the index, which is the middle disconnected, no matter what operating c4 can not use the index, only Using filesort up. About Using filesort Detailed See: [MySQL] Explain explain the Index Tuning combat

 

 

Case 4

analysis:

Only use the index to find c1, c2 and c3 for sorting, without the Using filesort .

 

Case 4.1

analysis:

And explain the results of Case 4 in the same, but the emergence of the Using filesort , because the index creation order for c1, c2, c3, c4, but when sorting c2 and c3 upside down position a. Combined B + tree index structure to think that the order of the index is c1, c2, c3, c4, c2 and c3 is now the order reversed for a moment, then the index has been under the original order sorted leaf nodes do not apply, because the leaf nodes in accordance with c1, c2, c3, c4 sort of order, certainly, and now I want c1, c3, c2, c4 ordering is different, so you can not use the index. In thinking about these statements have no time to use the index, the data must be combined with the index tree structure to understand .

 

Case 4.2

 

analysis:

C5 increased in the query, but as the results explain, because c5 did not create the index. c1 and c2 are constants equivalent query, so use to index and used as query filters and then sort the results according to the order by content.

 

Case 4.3

analysis:

And Case 4.1 contrast, does not appear in the Extra in the Using filesort , since c2 is a constant , is optimized in the ordering, so the index is not reversed, it will not appear Using filesort. Index from the data structure in view of this problem is where the c2 = 'a2' has a fixed value is a constant, c2 in order by the actual effect will be lost, MySQL bottom case can be detected to do the corresponding optimization, so that c2 sort order by the failure, the result set of a query only c3 sort, and c3 according to index data structure, c1, c2 are already set value, c3 can use the index in ready-made already sorted data without using using filesort.

 

5, group by query case

group by the underlying principle is implemented to perform an order by, sorting the results once, and then grouped according to the result of sorting. If you order by not using the index, it will sort files, sort files using the group by the system will generate a temporary table, that would explain the extra display the Using the Temporary . In short group by if you want to use the index must meet the order by the conditions of use of the index .

 

Case 5

analysis:

The query is only used in the index c1, c4 because the middle of the discontinuities, c2 and c3 for the group by the index sort order by the underlying The leftmost prefix rule, so key_len = 33, ref = const, shows the use of only one index.

 

Case 5.1

analysis:

Comparative Case 5, when the exchange group by c2 and c3 positions, according to the order by the beginning of said underlying index can not be used, only using file sort, and Using filesort Using temporary results appear extremely harsh. The reason: c3 and c2 and index creation in reverse order .

 

 

 

6, other queries situation

Case 6

analysis:

① created on c1, c2, c3, c4 the index range directly on c1, led to the failure of an index (in fact, there is also the underlying MySQL optimization, if the field is the first field where the use of the index range query, if the range is large, almost to scan all the data, MySQL will use full table scan, if this range is not great, so the underlying MySQL will still use indexes to query), a full table scan: type = ALL, ref = Null. Because at this time c1 is mainly used for sorting , not queries.

② use c1 sort, but the index failed, there was the Using filesort .

③ Workaround: Use a covering index . Is to overwrite the index field query field, to achieve coverage index, MySQL will not be a full table scan away use the index.

 

 

Case 7

analysis:

Although the same field index column sorted order and ascending order by default, where c2 desc into a descending, result in a different sort of the index , as the index of all the fields are sorted in the order in the same direction, if sorting occurred in different directions, then the index is an aligned naturally fails to produce Using filesort, and the type or index (index table index full scan, so it is a key_len of 132, indicating all four index field scanned, ALL full table scan, index that is slightly faster than ALL).

 

Case 8

EXPLAIN extended select c1 from test where c1 in ('a1','b1') ORDER BY c2,c3;

analysis:

For ordering, multiple conditions are also equal range queries, so the index fail, c2, c3 can not use an index, appears Using filesort. And this type is the index, a full table scan index.

 

7. Conclusions

  • MySQL supports two ways of sorting filesort and index , refer to the Using index MySQL scanning the index itself complete sequencing . index high efficiency, low filesort efficiency.
  • order by satisfying two conditions will be used Using index.
    • order by statement to use the leftmost forefront of the index .
    • Where clause and order by clause conditions are combined to meet the most front left index column.
  • As far as possible in the index column complete sequencing on, follow the indexing (order of the index was created) the most left-prefix rule when.
  • If you order by conditions not in the index column, it will generate Using filesort.
  • group by and order by very similar, and its essence is first sorted grouping , in accordance with the index creation order of the best left-prefix rule. Note that where above having, of where to write in not going to define the conditions defining HAVING.

Popular understanding of formulas:

   Full values match my favorite, the most left-prefix to comply;

   Take the lead in Big Brother can not die, the middle brother can not be broken;

   The column index less calculated , then the range of the whole failure;

   LIKE percentage write rightmost , covering indexes do not write the stars;

   Ranging from a null value there or, the index failed to use less.

 

Supplements: in and exsits optimization

Principle: small table-driven large table , the small data set to drive large data sets, small table data to be performed before a large table .

for  (int i = 0; i < 5; i++) {
    for (int j = 0; j < 1000; j++) {
    }
}
for  (int i = 0; i < 1000; i++) {
    for (int j = 0; j < 5; j++) {
        
    }
}

These two cycles for the first cycle for the outermost layer only needs to be performed five times, and the second outer layer do need to be performed 1,000 times, equivalent to SQL nested query is only a first splicing table five times, the first two required stitching 1000 form.

 

in : When B is set smaller than the data table A table data set, in of superior exists 

in is executed first B query, then the B content query to create a temporary table, then perform A query that order and exists is the opposite .

select * from A where id in (select id from B)

# Introduced for loop is equivalent to:

for select id from B

for select * from A where A.id = B.id

 

EXISTS : When B is set larger than the data table A table of data set, exists than in

The main query A data query into sub B some conditions are verified, in accordance with the verification result ( to true or false whether the query to determine the master) data retention

select * from A where exists (select 1 from B where B.id = A.id)

#Equivalent to

for select * from A    

for select * from B where B.id = A.id

ID field #A table B and table index should

 

in and exists optimization methods are to meet the principle of small table-driven large table .

  1. EXISTS (subquery) returns only TRUE or FALSE, and therefore sub-query SELECT * can also be SELECT 1 or select X, the official statement is ignored SELECT list of the actual implementation, there is no difference
  2. The actual implementation process EXISTS sub-query may be optimized rather than one by one through the comparison of our understanding
  3. EXISTS subquery can often be replaced with JOIN, concrete analysis of specific issues which require optimal

Other related articles: [MySQL] Explain explain the Index Tuning combat
                        [MySQL] MySQL cases can use the index and create index precautions
                        slow query configuration and use of [MySQL]
                       the most left-prefix principles and index [MySQL] index Optimization push
                        [] MySQL InnoDB row format, data pages and index structure underlying principle analysis

Published 54 original articles · won praise 47 · views 10000 +

Guess you like

Origin blog.csdn.net/cy973071263/article/details/104552572