Create a table with three fields.
All three fields are of type varchar. And made a composite index for the three fields
The next step is to verify that the index is valid
1.查询全部记录
EXPLAIN SELECT * FROM `handler`;The result is
It can be seen that the type is ALL, which is the so-called "full table scan". If it is to display all the data items in a data table, it is nothing. If the all type appears in a sql for searching data items, That usually means that your sql statement is in the most native state, and there is a lot of room for optimization.
Why do you say that? Because all is a very violent and primitive search method, it is very time-consuming and inefficient. Using all to find data is like this situation: there are 20,000 people in S school, I tell you you find Xiao Ming for me, and then how do you do it! Of course, you are looking for the 20,000 people in the school one by one. Even if you are lucky to be the first person to find Xiao Ming, you still can't stop, because you can't confirm whether there is another Xiao Ming until you find the 20,000 people. until the end. So, in almost all cases, we should avoid this type of lookup unless you have to.
2.使用一个索引,且使用仅使用组合索引的第一个索引
EXPLAIN SELECT * FROM `handler` where taskid = '1';The result is
It can be seen that he uses an index, and key_len is used to indicate the length of the selected index in bytes in this query. Usually, we can use this to judge how many columns are selected in the joint index.
3.使用两个索引,索引顺序按照组合索引
EXPLAIN SELECT * FROM `handler` where taskid = '1' and file_url = 'b';The result is
It can be seen that two indexes are used, and key_len has also become larger.
4.使用全部索引,且按照组合索引顺序
EXPLAIN SELECT * FROM `handler` where taskid = '1' and file_url = 'b' and file_md5 = 'bm';The result is
It is obvious that key_len has increased again, so all indexes are valid.
5.字段类型对索引的影响
EXPLAIN SELECT * FROM `handler` where taskid = 1;The result is
You can see that the type is ALL, and the rows field indicates the rows that may be scanned, because our table has only three rows of data, but all of them have been scanned, so it is determined that the index will not take effect when the data types are inconsistent
6.条件顺序对索引是否有影响
EXPLAIN SELECT * FROM `handler` where file_url = 'b' and file_md5 = 'bm' and taskid = '1';The result is
It can be seen that although the order of our where conditions is inconsistent with the order of the combined index, the combined index is still in effect, and the indexes written in where are all in effect
7.索引跳跃是否有影响
EXPLAIN SELECT * FROM `handler` where taskid = '1' and file_md5 = 'bm';
EXPLAIN SELECT * FROM `handler` where file_url = 'b' and file_md5 = 'bm';
The result is
You can see that the first sql uses an index. Since the file_url field is missing in the middle, the file_md5 index is not valid. Therefore, only one index is used
The second sql is a full table scan. Why, because it lacks taskid, and taskid is the first index of the composite index, so none of the indexes take effect. This may be the best explanation of the leftmost prefix principle.
8.范围查询是否影响索引
EXPLAIN SELECT * FROM `handler` where taskid = '1' and file_url = 'b' and file_md5 > 'cm';
The result is
The same three indexes are in effect.
9.当sql中出现不等于
EXPLAIN SELECT * FROM `handler` where taskid = '1' and file_url = 'b' and file_md5 != 'cm';
EXPLAIN SELECT * FROM `handler` where taskid != '2' and file_url = 'b' and file_md5 = 'cm';The result is
It can be found that no matter where != appears, it will cause the index to fail, resulting in a full table scan
Summarize
When using composite indexes, try to ensure that the field types are consistent. At the same time, don't skip the index. For example, if the composite index is abcd and the actual SQL is where a cd, then the cd index will not take effect. But if it is where dcba, the index is in effect. In addition, do not use != to judge the index field, otherwise it will cause all indexes to fail.
This practice is based on:
