Several cases of index invalidation caused by MySQL

Catalog

One 、 preparation

Two 、 Index invalidation rule

1. Use federated indexes first

2. Left most matching principle

3. The column index to the right of the range condition fails

4. Calculation 、 Function causes the index to fail

5. Index invalidation due to type conversion

6. It's not equal to (!= perhaps <>) Index failure

7.is null You can use index ,is not null Index not available

8.like With % start , Index failure

9.OR There are non indexed columns before and after , Index failure

10. The character set is not uniform

3、 ... and 、 Suggest

One 、 preparation

First prepare two tables to demonstrate ：

CREATE TABLE `student_info` ( `id` int NOT NULL AUTO_INCREMENT, `student_id` int NOT NULL, `name` varchar(20) DEFAULT NULL, `course_id` int NOT NULL, `class_id` int DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8;CREATE TABLE `course` ( `id` int NOT NULL AUTO_INCREMENT, `course_id` int NOT NULL, `course_name` varchar(40) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8;# Prepare the data select count(*) from student_info;#1000000select count(*) from course; #100 Two 、 Index invalidation rule 1. Use federated indexes first

Here's one sql The statement has no index ：

# The average time taken 291 millisecond select * from student_info where name='123' and course_id=1 and class_id=1;

We optimize its query efficiency by building indexes , There are several schemes as follows ：

① Build a normal index ：

# Build a normal index create index idx_name on student_info(name);# The average time taken 25 millisecond , see explain Implementation plan , What we use is idx_name Index query select * from student_info where name='MOKiKb' and course_id=1 and class_id=1;

② On the basis of ordinary index , Add the union index ：

#name,course_id A joint index of create index idx_name_courseId on student_info(name,course_id);# This query statement generally uses the union index , Instead of a normal index , See optimizer decisions for details # The average time taken 20msselect * from student_info where name='zhangsan' and course_id=1 and class_id=1;

  You can see , When multiple indexes are available , Systems generally prefer to use longer federated indexes , Because federated indexing is faster , This should also be well understood , The premise is to comply with the leftmost matching principle of the joint index .

If you create another name,course_id,class_id A joint index of , So the above sql The statement will use this... Unexpectedly key_len Longer federated indexes ( The surprise is that the optimizer may choose a better solution , If it's faster ).

Federated indexing is not necessarily faster than normal indexing , For example, the first condition filters all records , Then there is no need to use the subsequent index .

2. Left most matching principle # Delete the index created in the previous example , Create a new union index of three fields ,name-course_id-cass_idcreate index idx_name_cou_cls on student_info(name,course_id,class_id);

① All union indexes match ：

# The index of the associated field is relatively complete explain select * from student_info where name='11111' and course_id=10068 and class_id=10154;

  The sql Statement conforms to the leftmost prefix principle , The fields in each field condition exactly match the union index . This situation is optimal , Because relying on a union index can quickly find , No additional queries are required .

② The rightmost missing case of the union index ：

explain select * from student_info where name='11111' and course_id=10068;

  The sql In a statement condition , Does not contain all the conditions of a union index , Instead, the right half is erased , The index used by this statement is still the associated query , Only a part of it is used , By looking at key_len We can know that there is less 5 byte , this 5 Bytes correspond to class_id, prove class_id It doesn't take effect (where There is no , Of course not ).

Empathy , erase where Medium course_id Field , The union index will still be in effect , It's just key_len It will decrease .

③ Missing in the middle of the union index ：

# The field in the middle of the union index is not used , There are both left and right explain select * from student_info where name='11111' and class_id=10154;;

Above sql The statement still uses the union index , But it's key_len It's getting smaller , Only name The field uses the index , and class_id Although the field is in the union index , But because it does not conform to the leftmost matching principle GG 了 .

Whole sql The execution flow of the statement is ： First in the union index B Find all in the tree name by 11111 The record of , Then filter out these records in full text class_id No 10154 The record of . There is one more step for full-text search , Compared with ① and ② The performance will be worse .

④ The leftmost missing case of the union index ：

explain select * from student_info where class_id=10154 and course_id=10068;

  This case is a special case of the previous case , The leftmost field in the union index was not found , So although there are other parts , But it all failed , It is full-text search .

Conclusion ： The leftmost matching principle means that the query starts from the leftmost column of the index , And you can't skip columns in the index , If you skip a column , The index will be partially invalidated ( All subsequent field indexes are invalid ).

Be careful ： When creating a federated index , The order of the fields is frozen , The leftmost match is compared according to this order ; But in the query statement ,where The order of the fields in the condition is variable , This means that there is no need to follow the order of the associated index fields , as long as where If there is one in the conditions .

3. The column index to the right of the range condition fails

Undertake the above joint index , Use as follows sql Inquire about ：

#key_len=> name:63,course_id:5,class_id:5explain select * from student_info where name='11111' and course_id>1 and class_id=1;

 key_len Only 68, Represents... In the associated index class_id Not used , Although it conforms to the leftmost matching principle , But because > The symbol invalidates the index to the right of the condition field in the associated index .

But if >= No ：

# No >、<, It is >=、<=explain select * from student_info where name='11111' and course_id>=20 and course_id<=40 and class_id=1;

  The index on the right is not invalidated ,key_len by 73, The indexes of all fields are used .

Conclusion ： To make full use of indexes , Sometimes we can put >、< Equivalent to >=、<= In the form of , Or there may be <、> The conditional fields of the are placed at the back of the associated index as far as possible .

4. Calculation 、 Function causes the index to fail # Delete the previous index , New creation name Index of field , Easy to demonstrate create index idx_name on student_info(name);

There is a need , find name by li Student information at the beginning ：

# Index used explain select * from student_info where name like 'li%';# Unused index , Take longer explain select * from student_info where LEFT(name,2)='li';

The top two sql Statements can meet the requirements , However, the first statement uses an index , The second one does not , A little change is really a world apart .

Conclusion ： Using functions in fields will make the optimizer unable to start ,B The values in the tree may not match the results of the function , So you won't use indexes , That is, index failure . Fields can be used without functions .

similar ：

# No index will be used explain select * from student_info where name+''='lisi';

Similar operations on fields can also lead to index invalidation .

5. Index invalidation due to type conversion # Can't use name The index of explain select * from student_info where name=123;# Use to index explain select * from student_info where name='123';

Above ,name The fields are VARCAHR Type of , But the comparison value is INT Type of ,name The value of is implicitly converted to INT Compare the types again , In the middle is equivalent to a string that is converted to INT Function of type .

6. It's not equal to (!= perhaps <>) Index failure # Create index create index idx_name on student_info(name);# Index failure explain select * from student_info where name<>'zhangsan';explain select * from student_info where name!='zhangsan';

The index will not be used in the case of not equal to . because != It means to search the full text , No index .

7.is null You can use index ,is not null Index not available # You can use index explain select * from student_info where name is null;# Index failure explain select * from student_info where name is not null;

Similar to the previous rule ,!=null. Empathy not like You can't use indexes .

It is best to set... When designing tables NOT NULL constraint , For example, will INT The default value of type is set to 0, Set the string default value to ''.

8.like With % start , Index failure # Index used explain select * from student_info where name like 'li%';# Index failure explain select * from student_info where name like '%li';

As long as % The index cannot be used at the beginning , Because if % start , stay B It is not easy to find in the data sorted by tree .

9.OR There are non indexed columns before and after , Index failure # Create an index create index idx_name on student_info(name);create index idx_courseId on student_info(course_id);

If or There are indexes before and after ：

# Use index explain select * from student_info where name like 'li%' or course_id=200;

  If one of them has no index ：

explain select * from student_info where name like 'li%' or class_id=1;

Then the index fails , Suppose you still use indexes , Then it becomes to search through the index first , Then we can query the whole table according to the fields without indexes , This method is not as fast as direct full table query .

10. The character set is not uniform

If the character set is different , There will be implicit conversions , Indexes will also fail , All should use the same character set , Prevent this from happening .

3、 ... and 、 Suggest

For single column indexes , Try to choose the current query Better filtering index

When selecting a composite index ,query The most filterable fields should be as close to the top as possible

When selecting a composite index , Try to include the current query in where Index of more fields in clause

When selecting a composite index , If a range query may appear in a field , Try to put it back

  This is about MySQL The article on several situations that lead to index invalidation is introduced here , More about MySQL Please search the previous articles of SDN or continue to browse the related articles below. I hope you can support SDN more in the future ！