When you create an index n columns, you need to follow the "most left-prefix" principle.
创建表：create table abc(a varchar(32) not null, b varchar(32), c date );
Creating an ordinary index: create index in_abc_acb on abc (a, c, b);
1, select * from abc where b = 'bbb' and c = sysdate; not use the index, must be used to the left of the first field;
2, select * from abc where a like '1%' and c = sysdate; a index will be used, C is not encountered range (>, <, between, like) matches a query is stopped;
3, select * from abc where trim (a) = 'a'; not use the index, before the addition of the function field (expression) index is suppressed. where a = 'a' and c + 1> sysdate, c does not use the index, and where a = 'a' and c> sysdate - 2, the index will be used;
4, select * from abc where b like 'b%' and c = sysdate and a = 'a'; acb index can be used, because the index is matched from left to right, in and out of order can be =;
The most left-prefix principle index:
Usually when we establish a joint index, which is the index on multiple fields, we believe that the establishment of the index over the students will find, whether or oralce mysql will let us choose the order of the index, such as we would like in a, b, c the three fields to establish a joint index, we can choose what you want the order of priority, a, b, c, or b, a, c or c, a, b and so on. Why database will let us choose the order of the fields it? Not all three fields of joint index it? Here it leads to the most left-prefix principles of database indexes.
For example: index index1: (a, b, c) there are three fields, when we use the sql statement to query, you will find not according to our imagination to take the index in many cases.
select * from table where c = '1'
The sql statement is not going to go index1 index
select * from table where b =‘1’ and c ='2'
This statement does not go index1 index.
What statement will go index1 index it?
the answer is:
select * from table where a = '1' select * from table where a = '1' and b = ‘2’ select * from table where a = '1' and b = ‘2’ and c='3'
We can find a common ground, that is all sql query statements go inside index index1 are presented with a field, then the question is, index1 index of the leftmost column is a field, the query is not contained in a will We will take the index it?
E.g:
select * from table where a = '1' and c= ‘2’
This sql statement, according to previous understanding, that contains a field, will take the index, but it is not all fields are gone index it?
Let's do an experiment:
I have a table:
The establishment of a joint index, prinIdAndOrder there are three fields PARENT_ID, MENU_ORDER, MENU_NAME
The next test before the statement:
EXPLAIN SELECT t.* FROM sys_menu t WHERE t.`PARENT_ID` = '0' AND t.`MENU_NAME` = 'System Tools'
Before the sentence is equivalent to sql select * from table where a = '1' and c = '2' the sql statement, we take a look at an explain plan:
You can see the index go prinIdAndOrder, but next key_len = 303, but the truth key_len should be greater than 303, and why? Because the type PARENT_ID field is varchar (100) NULL, so key_len = 100 * 3 + 2 + 1 = 303, but there MENU_NAME it! Key_len specific calculation method, we can Baidu, my character set table is utf-8, is calculated in different character sets the table is not the same. Here explain plan shows key_len only 303, just explain away the field PARENT_ID index did not take the index MENU_NAME.
This is part of the most left-prefix principle, the index index1: (a, b, c), only take a, a, b, a, b, c three types of queries, in fact, have a little problem here that, a, c is gone, but just take a field index, will not go c field.
There is also a special case under description, select * from table where a = '1' and b> '2' and c = '3' of this type will only have to go indexes a and b, c will not go.
Like select * from table where a = '1' and b> '2' and c = '3' sql statement of this type, in a, b after the completed index, c is certainly random, so no c France take the index, the database will feel not as full table scan c field to the quick. I do not know to say it did not feel this one is always a bit far-fetched to say.