Understand the index of like in MySQL

Prepare the data

Table structure ：

CREATE TABLE `user` (
 `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
 `name` varchar(30) COLLATE utf8mb4_bin DEFAULT NULL,
 `age` int(11) DEFAULT NULL,
 `create_time` datetime DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;


Table data ：

like % in front

Look at the following two first  SQL  sentence

select * from user where name like '% Zhang %';

select * from user where name like '% Zhang ';

These two SQL Statements are of the same type , Everyone should know , They are not indexed .

Why not index

Left most matching principle .B+ The underlying storage of the tree is sequential ,% On the left side, it indicates that the content prefix we are looking for is uncertain , If you are not sure, you can only search and compare one by one , This is equivalent to scanning the entire secondary index tree , That's not all , Because you want to query all the fields , So in the middle, you have to go back to the table to query on the primary key index . It's better to scan the whole table directly .

Here's another one  SQL  sentence

select id, name from user where name like '% Zhang '; 

We just looked

id

,

name

The field found can be indexed ,Why？

Why did you go to the index again

Here is the overlay index , Although the entire secondary index was scanned , But the secondary index contains all the query fields , There is no need to query the table again .（ Scanning auxiliary indexes is more efficient than full table scanning .）

like % rearwards

in the light of  

like

The optimization of is usually to

%

Put it in the back , In this way, the query efficiency can be improved by indexing the data .

The problem is coming. , So you can definitely use the index ？

select * from user where name like ' Zhang %';
select * from user where name like ' Zhou %'; 

Think about it   

Obviously

like  Zhang %

No index , and  

like  Zhou %

The index is gone , alike

%

Why did some of them leave the index behind , Some didn't go .

Why not index

The first said

%

stay

like

Most of the following scenarios are indexed , But there are exceptions , In this case , With

Zhang

The data dispersion at the beginning is low , The optimizer determines through the secondary index

idx_name

The query cost may be greater than the full table scan , You can scan the whole table directly .

So the index fields we create should be as discrete as possible , Otherwise, the index may not be used .

Force Index

If the optimizer feels wrong , You can force the use of indexes ：

select * from user force index(idx_name) where name like ' Zhang %';

The latter

finish writing sth.  SQL  sentence , Be sure to look at its implementation plan , See if it's the same as we expected .

In some cases , When executed EXPLAIN Command to SQL In the analysis of a sentence , You will find that the optimizer does not select the index to look up the data , But by scanning the clustered index , That is to scan the whole table directly to get the data . This is often the case with range lookups 、JOIN Link operation, etc .

for example ：SELECT * FROM orderdetails WHERE orderid＞10000 and orderid＜102000;

Why is that ？ The reason is that the data you want to select is the whole line of information , and OrderID The index can't cover the information we want to query , So in the right OrderID After the index queries the specified data , You also need a bookmark access to find information about the entire line of data . although OrderID The data in the index is stored in order , But again, it's unordered , So it becomes a discrete read operation on disk . If the amount of data required to be accessed is small , The optimizer will still select the secondary index , But when the data accessed accounts for a large part of the data in the whole table （ It's usually 20% about ）, The optimizer will choose to look up the data through aggregate indexes . Because it's been mentioned before , Sequential reading is much faster than discrete reading .

Excerpt from :  Jiang Cheng Yao . 《MySQL Technology insider ：InnoDB Storage engine ( The first 2 edition ) 》.