The leftmost prefix principle of MySQL

Let me talk about it. MySQL The leftmost prefix principle of ?
The leftmost prefix principle is the leftmost priority , When creating a multi-column index , According to business needs ,where The most frequently used column in the clause is at the far left . mysql It will keep matching to the right until it encounters a range query (>、<、between、like) Just stop matching , such as a = 1 and b = 2 and c > 3 and d = 4 If set up (a,b,c,d) Index of order ,d There is no index , If set up (a,b,d,c) The index of can be used ,a,b,d The order of can be adjusted at will .

= and in You can order , such as a = 1 and b = 2 and c = 3 establish (a,b,c) Indexes can be in any order ,mysql The query optimizer will help you optimize it into a form that the index can recognize .

Let's talk about prefix index ？
Because maybe the fields we index are very long , This takes up memory space , It's not good for maintenance . So we thought , If only the front common part of a long field is used as an index , It will have a super doubling effect . however , We need to pay attention ,order by Prefix index is not supported .

The process is ：

First calculate the selectivity of the complete column :select count(distinct col_1)/count(1) from table_1

And then calculate the selectivity of different prefix lengths :select count(distinct left(col_1,4))/count(1) from table_1

After finding the optimal length , Create prefix index :create index idx_front on table_1 (col_1(4))

Do you know about index push down ？
MySQL 5.6 Index push down optimization is introduced . Default on , Use SET optimizer_switch = ‘index_condition_pushdown=off’; You can turn it off .

With index push down optimization , You can reduce the number of times to return to the table

stay InnoDB Is only valid for secondary indexes

The examples and explanations given in the official documents are as follows ：

stay people_table There is a secondary index in (zipcode,lastname,address), Query is SELECT * FROM people WHERE zipcode=’95054′ AND lastname LIKE ‘%etrunia%’ AND address LIKE ‘%Main Street%’;

If index pushdown is not used , be MySQL Will pass zipcode=’95054’ Query the corresponding data from the storage engine , Back to MySQL Server side , then MySQL Server based on lastname LIKE ‘%etrunia%’ and address LIKE ‘%Main Street%’ To determine whether the data meet the conditions

If index push down technology is used , be MYSQL First it will return the match zipcode=’95054’ The index of , And then according to lastname LIKE ‘%etrunia%’ and address LIKE ‘%Main Street%’ To determine whether the index meets the conditions . If you qualify , Then locate the corresponding data according to the index , If it doesn't meet , directly reject fall .

How to check MySQL Does the statement use an index ？
adopt explain, For example: ：

EXPLAIN SELECT * FROM employees.titles WHERE emp_no=‘10001’ AND title=‘Senior Engineer’ AND from_date=‘1986-06-26’;

id select_type table partitions type possible_keys key key_len ref filtered rows Extra
1 SIMPLE titles null const PRIMARY PRIMARY 59 const,const,const 10 1
id： stay ⼀ individual ⼤ In the query statement of SELECT All keywords correspond to ⼀ A unique ⼀ Of id , Such as explain select * from s1 where id = (select id from s1 where name = ‘egon1’); first select Of id yes 1, the second select Of id yes 2. Sometimes there are two select, however id But it's all 1, This is because the optimizer turns a subquery into a join query .

select_type：select The type of query corresponding to the keyword , Such as SIMPLE,PRIMARY,SUBQUERY,DEPENDENT,SNION .

table： The table name corresponding to each query .

type：type Fields are important , It provides an important basis to judge whether the query is efficient . adopt type Field , We judge that this query is Full table scan still An index scan etc. . Such as const( In the case of primary key index or unique secondary index for equivalent matching ),ref( ordinary ⼆ Level index column and constant into ⾏ Equivalence match ),index( Scan the overlay index of the full table index ) .

Generally speaking , Different type The performance relationship for the type is as follows : ALL < index < range ~ index_merge < ref < eq_ref < const < system ALL Type because it is a full table scan , So under the same query conditions , It's the slowest . and index Type of query is not a full table scan , But it scans all the indexes , Therefore ratio ALL Slightly faster type .

possible_key： Index that may be used in the query ( You can delete the ones you don't need , Reduce optimizer optimization time ) .

key： This field is MySQL Index actually used in the current query .

filtered： The querier predicts the percentage that meets the next query condition .

rows It's also an important field . MySQL Query optimizer based on statistics , Estimate SQL Number of data rows to scan to find the result set . This value is very intuitive SQL The efficiency of , In principle, rows The less, the better. .

extra： It means extra information , Such as Using where,Start temporary,End temporary,Using temporary etc. .