Seven common index failure scenarios in MySQL compound index


#Database description The table emp used is as follows:

CREATE TABLE emp(
	id INT(11) NOT NULL AUTO_INCREMENT,
	empno INT NOT NULL,
	NAME VARCHAR(20) DEFAULT NULL,
	age INT(3) DEFAULT NULL,
	deptid INT(11) DEFAULT NULL,
	PRIMARY KEY (id)
)
ENGINE = INNODB AUTO_INCREMENT=1 DEFAULT CHARSET =utf8;

Then randomly insert 500,000 pieces of data in it

Try to build a compound index in the order of age_name_deptid, and query the execution

CREATE INDEX idx_age_name_deptid ON emp(age, NAME, deptid);

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`age`=30
AND emp.name='abcd'
AND emp.`deptid`=4;

The results are as follows: The
Insert picture description here
above is the normal usage of the index. It can be seen that after the index is used, the physical row is reduced from 500000 to 1, which improves the efficiency. Here are seven index failure scenarios based on this

**


1. Case 1 The query item is missing in the first position


**

CREATE INDEX idx_age_name_deptid ON emp(age, NAME, deptid);

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE  emp.name='abcd' AND emp.`deptid`=4;

The results are as follows: the
search result
physical row rows is close to 500000, and it can be seen that the query result is a full table query


2. Case 2 Index interruption, the index after the interruption is invalid

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.`deptid`=4;

The results are as follows: It
Insert picture description here
can be seen that although the physical rows of the query have dropped to more than 40,000, it is more efficient than a full table scan, but worse than the best case. This is because the order of the established index is age_name_deptid, and this query is age_deptid, it is interrupted at the name, and the index after the interruption becomes invalid.

3. Case 3 Use a function on the index column

CREATE INDEX idx_name ON emp(NAME);

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`name` LIKE 'abc%';
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE LEFT(emp.`name`,3) = 'abc';

The first query result The

second query result
Insert picture description here

4. Scenario 4 The storage engine cannot use the column to the right of the range condition in the index **

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.`deptid`=4 AND emp.name='abcd';
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.`deptid`>=4 AND emp.name='abcd';

5. Scenario 5: Index cannot be used when inequality occurs

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE  emp.`deptid`=4;

CREATE INDEX idx_deptid ON emp(deptid);

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE  emp.`deptid`=4;
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE  emp.`deptid`<>4;

The results are as follows:
Insert picture description here

* 6. In case 6 is not null can not use index, but is null can use index

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE age IS NULL;
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE age IS NOT NULL;

7. Index is invalid in case 7 like'%xxx' *

EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE NAME LIKE 'abc';
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE NAME LIKE 'abc%';
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE NAME LIKE '%abc';

Guess you like

Origin blog.csdn.net/vivian233/article/details/109801868