Indexing best practices

Index best practices

establish demo surface

CREATE TABLE `employees` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(24) NOT NULL DEFAULT '' COMMENT ' full name ',
`age` int(11) NOT NULL DEFAULT '0' COMMENT ' Age ',
`position` varchar(20) NOT NULL DEFAULT '' COMMENT ' Position ',
`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ' Entry time ',
PRIMARY KEY (`id`),
KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
 ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT=' Employee record form ';

 INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());
 INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei',23,'dev',NOW());
 INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());

1. Full match

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei';

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';

2. The leftmost prefix rule

If you index multiple columns , Follow the leftmost prefix rule . It means that the query starts from the left front of the index and does not skip the columns in the index , If you hit a non indexed column , Will go through the global index .

EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;

EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';

3. Do nothing on the index column （ Calculation 、 function 、（ Automatically or Manual ） Type conversion ）, It will cause index invalidation and turn to full table scan

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei';

EXPLAIN SELECT * FROM employees WHERE left(name,3) = 'LiLei';

to hire_time Add a normal index ：

Normal index ：

 EXPLAIN select * from employees where hire_time ='2022-07-24 20:10:22';

There is an index invalidation after time type conversion ：

 EXPLAIN select * from employees where date(hire_time) ='2018-09-30';

Convert to date range query , Can walk the index ：

EXPLAIN select * from employees where hire_time >='2018-09-30 00:00:00' and hire_time <='2018-09-30 23:59:59';

Restore original index state

ALTER TABLE `employees` DROP INDEX `idx_hire_time`;

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

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age > 22 AND position ='manager';

When age When using range query , Hit is range, instead of ref, It has been inferior by one level ;

from ken_len It can be seen that , After the range query, the length becomes 78, explain age Subsequent index misses .

5. Try to use overlay index （ Queries that only access the index （ Index columns contain query Columns ））, Reduce select * sentence

EXPLAIN SELECT name,age FROM employees WHERE name= 'LiLei' AND age = 23 AND position='manager';

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';

from Extra Analysis can be seen ,select * Will result in failure to hit the index column .

6.mysql In use is not equal to （！= perhaps <>）,not in ,not exists Unable to use the index will result in a full table scan < Less than 、 > Greater than 、 <=、>= these ,mysql The internal optimizer will, based on the retrieval ratio 、 Multiple factors such as table size are used to evaluate whether index is used as a whole

EXPLAIN SELECT * FROM employees WHERE name != 'LiLei';

Negative index （！、not etc. ） I don't usually go through the index , The range query determines whether to go to the index according to the judgment of the optimizer .

7.is null,is not null In general, you cannot use indexes

EXPLAIN SELECT * FROM employees WHERE name is null

8.like Start with a wildcard （‘$abc…’）mysql Index failure will become a full table scan operation

EXPLAIN SELECT * FROM employees WHERE name like '%Lei'

EXPLAIN SELECT * FROM employees WHERE name like 'Lei%'

Similar query like in , With "%“ Generally, the index is not used at the beginning , With ”%" The end can be indexed .

With "teasir%" ending , amount to =“teasir”, Naturally, you can go to the index .

problem ： solve like’% character string %' Indexing methods that are not used ？

a） Use overlay index , The query field must be an override index field .

b） If you can't use overlay index, you may need to use search engine

9. String index is invalid without single quotation marks

EXPLAIN SELECT * FROM employees WHERE name = '1000';

EXPLAIN SELECT * FROM employees WHERE name = 1000;

The analysis shows that , The index is invalid without single quotation marks .

10. To use less or or in, When you use it to query ,mysql Not necessarily index ,mysql The internal optimizer will, based on the retrieval ratio 、 Overall evaluation of multiple factors such as table size Estimate whether to use index , See scope query optimization for details

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' or name = 'HanMeimei';

Try to use other logic to reduce or perhaps in Use .

11. Range query optimization

Add a single index to age

ALTER TABLE `employees` ADD INDEX `idx_age` (`age`) USING BTREE ;
explain select * from employees where age >=1 and age <=2000;

The reason why I didn't go to the index ：mysql The internal optimizer will, based on the retrieval ratio 、 Multiple factors such as table size are used to evaluate whether index is used as a whole . Take this example , May be Because the amount of data in a single query is too large, the optimizer finally chooses not to go to the index An optimization method ： You can divide a large area into several small areas

explain select * from employees where age >=1 and age <=2;

If the range query does not go through the index , Analyze whether it is due to the amount of data , Optimizer optimization leads to .

Restore original index state

 ALTER TABLE `employees` DROP INDEX `idx_age`;

Summarized below ：

The range query will hit the current field index （a=3 and b>4; Will hit b）, Similar queries will not hit the current field index (a=3 and b like ‘%kk’; It won't hit b).