Continuous soul torture from two MySQL indexes of interviewers

【 From both sides of the interviewer MySQL Indexed continuous soul torture 】

This issue's main interview test site

Log in and copy

 The process of index maintenance ？ Page splitting ？ Page merge ？

     

      
1.
     

Log in and copy

 A brief introduction to the test site of an interviewer B+ Tree index search process ？

     

      
1.
     

Log in and copy

 What is a return form ？

     

      
1.
     

Log in and copy

 What is the index coverage of the interviewers ？ Use scenarios ？

     

      
1.
     

Log in and copy

 When will the index fail ？

     

      
1.
     

Log in and copy

 In which cases does the interviewer take the test , You may face the problem of index invalidation ？

     

      
1.
     

Log in and copy

 Interviewer's test point or What are the scenarios of index walking and index invalidation ？

     

      
1.
     

Log in and copy

 In which cases should an index be created ？

     

      
1.
     

Log in and copy

 The leftmost prefix principle of the joint index of interviewers ？

     

      
1.
     

Log in and copy

 The index of the interviewer's test site is pushed down ？

     

      
1.
     

I'm brother fat , An unprofessional interviewer ！

I'm Jiong , A rookie looking for a job ！

I'm sorry to say ： Xiaobai's biggest fear in an interview is that the interviewer's knowledge is too general , I can't locate the key problem point quickly ！！！

---

---

The process of index maintenance ？ Page splitting ？ Page merge ？

B+ Tree to maintain index order , Necessary maintenance should be done when inserting or deleting , When necessary, it may involve Page splitting , Page merge The process ！

First, assume that each leaf node （ Data page or disk block ） Can only store 3 Indexes and data records , Pictured

situation 1、 New row record ,ID=3, here 【 Data pages 1】 under , Only need data2 Then add ID=3 The line record of ,B+ The overall structure of the tree does not need to be adjusted

situation 2、 New row record ,ID=8, here 【 Data pages 2】 Is full , You need to apply for a new data page , Then move some of the data in the past . This process is called Page splitting .

The page splitting process consumes performance , At the same time, the utilization of space is also reduced

If there is division, there is merger , When two adjacent pages are deleted due to data , After a very low utilization , Will merge data pages . The process of merger , It can be regarded as the reverse process of the splitting process .

When two adjacent pages are deleted due to data , After a very low utilization , Will merge data pages . The process of merger , It can be regarded as the reverse process of the splitting process .

【 Data pages 2】 Deleted ID=7,ID=8 The line record of , here 【 Data pages 2】【 Data pages 3】 Utilization is very low , Page merge will take place .

A brief introduction to the test site of an interviewer B+ Tree index search process ？

Prepare a user list , among id Primary key ,age For general index

Log in and copy

CREATE TABLE `user` (
  `id` int(11) PRIMARY KEY,
  `name` varchar(255) DEFAULT NULL,
  `age` int(11) DEFAULT NULL
  KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

     

      
1.
      
2.
      
3.
      
4.
      
5.
      
6.
     

select * from user where age=22 Briefly B+ Tree index search process ？

Suppose the record to be queried

Log in and copy

 id=5,name=" Zhang San ",age=22

     

      
1.
     

MySQL A tree is maintained for each index B+Tree Tree index ,

Primary key index non leaf node maintains index key , Leaf nodes store row data ;

A non primary key index is also called a secondary index , Non leaf nodes store primary keys ;

B+ Tree index search process

search criteria age=22, Let's go idx_age Indexes , First load idx_age Tree index , find age=22 The record of , obtain id=5

Back to table search , Load the primary key index tree , find id=22 The record of , Get the whole line of data

What is a return form ？

idx_age The secondary index tree finds the primary key id after , go back to id Primary key index search process , It's called back to the table .

Not all non primary key index searches , You need to search back to the table , That is to say, index coverage .

What is the index coverage of the interviewers ？ Use scenarios ？

In the example mentioned above , Because the data needed for query results is only on the primary key index , So I have to go back to my watch .

If it's in the data column of the query , You can get the desired result directly from the index column , You don't need to go back to the form , Also known as index overlay ！

The advantage of index coverage

1. You can avoid being right Innodb Second query of primary key index
2. You can avoid MyISAM Table for system calls
3. You can optimize the cache , Reduce disk IO operation

Modify the chestnut above , Satisfy index coverage conditions ？

Log in and copy

select id, age from user where age=22

     

      
1.
     

Information for query ,id,age Can be directly in idx_age Index tree , No need to go back to the table to search .

Tree searches can be reduced by overwriting the index , Significantly improve query performance , So using overlay index is a common
Performance optimization means of .

Index is a double-edged sword , While providing quick sort search , The maintenance of index fields also has to pay a corresponding price .

therefore , A trade-off is needed when building redundant indexes to support coverage indexes

The index of the interviewer's test site is invalid ？

Index created , Is it effective , Or say SQL Statement does not use index query ？

One of the most common query scenarios , establish idx_name Indexes

Log in and copy

select * from t_user where user_name like '%mayun100%';

     

      
1.
     

Is this query indexed ？

Log in and copy

select * from t_user where user_name like 'mayun100%';

     

      
1.
     

Is this query indexed ？

What are the situations of the interviewers , You may face the problem of index invalidation ？

1. like wildcard , With the left side open , Full table scan
2. or Condition screening , May cause index to fail
3. where Use... For index columns in mysql Built in functions for , It must fail
4. where Operation on index columns in （ Such as ,+、-、*、/）, It must fail
5. Different types , Implicit type conversion , Index invalidation caused by
6. where The index column in the statement uses a negative query , May cause index to fail Negative queries include ：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE etc. . among !< !> by SQLServer grammar .
7. The index field can be null, Use is null or is not null when , May cause index to fail
8. Index invalidation caused by implicit character encoding conversion
9. In the union index ,where The index column in violates the leftmost matching principle , It must cause the index to fail
10. MySQL The final choice of the optimizer , Don't walk index

Interviewer's test point or What are the scenarios of index walking and index invalidation ?

or What are the scenarios of index walking and index invalidation ?

OR It's connected to the same field , The same index

Log in and copy

explain select * from t_user where user_name = 'mayun10' or user_name = 'mayun1000'

     

      
1.
     

OR Two different fields are connected , Don't walk index

to address Column increase index

Log in and copy

alter table t_user add index idx_address(address);
explain select * from t_user where user_name = 'mayun10' or address = ' Hangzhou, Zhejiang 12';

     

      
1.
      
2.
     

OR Two different fields are connected , If both fields have indexes , Go to the index

（ Insert , Next issue ：《MySQL Interview notes 》 Verification of several index failure scenarios ）

Do pay attention to ： I'm sorry

Interview notes series .

In which cases should an index be created ？

1. Primary key automatically creates unique index

2. Frequently queried fields

3.JOIN Relational query , Index columns as foreign key relationships

4. Single key / The choice of Composite Index , High and low tendency to create composite index , Follow the leftmost prefix matching principle when creating

5.ORDER BY Fields sorted in the query , Sorting field greatly improves sorting speed through index access

6.GROUP BY You need to group fields or statistics fields in a query

The leftmost prefix principle of the joint index of interviewers

MySQL Create multi column indexes （ Joint index ） The principle of having the leftmost prefix , That is, the leftmost priority

When MySQL It's a joint index , Suppose (a,b,c) Column as a union index , that MySQL What are the rules of achievement ？

We know MySQL Will maintain one for each index B+Tree, Non leaf node storage index key, Leaf nodes store row data data.

Joint index (a,b,c) It's kind of set up (a), (a,b), (a,b,c) Three indexes ,MySQL When assembling the index tree , It's built from left to right B+Tree Of the union index tree .

Match index case one

** hypothesis （a,b,c）** The value to search for in the index is (‘ Zhang San ’, 21, 100) , When retrieving data , The order of matching is a,b,c.

B+Tree Will give priority to a To determine the next step of the search direction , If a Compare the same again b and c, Finally, the retrieved data is obtained ;

Matching index case two

** hypothesis （a,c）** The value to search for in the index is (‘ Zhang San ’, 100) , When retrieving data , The order of matching is a,b,c.

B+Tree Use a To specify the search direction , But the next field b defect , So we can only put a It's equal to Zhang San's data , And then match c yes 100 The data of .

Match index case 3

** hypothesis （b,c）** The value to search for in the index is (‘ Zhang San ’, 21) , When retrieving data , No matching order

B+Tree I don't know which node to check next , Because when you build the search tree a It's the first comparison factor , It has to be based on a Search to know where to search next . At this time, the index fails ！

Index items are sorted according to the order of the fields in the index definition , The leftmost prefix can be the leftmost... Of the union index N A field , It can also be the leftmost of a string index M Characters .

The index of the interviewer's test site is pushed down ？

Index push down , That is to reduce the search times of secondary index return table ！！！

Popular said , Reduce the number of times to query the primary key index tree , Reduce disk IO

Set up a joint index idx_age_weight

Log in and copy

select * from user where age = 11 and weight = 98

     

      
1.
     

5.6 The previous search process was

stay idx_age_weight All of them are matched in the index tree age = 11 Indexes , Get the primary key id, Go back to the table and compare one by one weight Field

Here's the picture , Need to carry out 3 Second return table search operation

5.6 After the search process is
stay idx_age_weight All of them are matched in the index tree age = 11 Indexes , By the way, yes weight Field to judge , To filter out weight = 100 The record of , Then go back to the table search .

Here's the picture , Just do it 2 Second return table search operation `

---

recommend MySQL Related leisure reading ：

The first paragraph , Index interview questions recommend reading one ： 【 From the interviewer side MySQL Indexed continuous soul torture 】

The second paragraph , Index interview questions recommended reading 2 ： 【 From both sides of the interviewer MySQL Indexed continuous soul torture 】

The third paragraph , Index failure scenario interview questions are recommended to read ： 【 interviewer ： Tell me about the MySQL Index failure scenario , How did you solve ？】

The fourth paragraph , Query cache interview questions, recommended reading ： 【 interviewer ： What scenario will lead to MySQL Cache invalidation ？ Whether the production environment should be started or not MySQL cache ？】

The fifth paragraph , To be updated ？ Casual reading is recommended ： 【 I'm sorry 】

More highlights , Welcome to WeChat official account. ： I'm sorry ( Or search for ：jiongmefeishi)