MySQL学习笔记(2)——索引

文章目录

• 索引简介
• 是什么:
• 目的：
• 缺点：

索引分类

• 单值索引：
• 唯一索引：
• 复合索引：

索引性能分析（explain）

索引优化

• 单表情况
• 双表情况
• 内连接
• 左外连接

索引优化法则（技巧）

• 1.尽量全值匹配
• 2.最佳左前缀法则
• 3.不在建索引的列上做任何操作
• 4.范围条件右边的索引会失效
• 5.尽量使用覆盖索引
• 6.MySQL在使用!=或者<>会导致索引失效
• 7.is null和is not null无法使用索引
• 8.like以通配符%开头会导致索引失效
• 9.字符串不加引号索引失效
• 10.用or关键词会使得索引失效

索引简介

是什么:

帮助MySQL高效获取数据的数据结构(B树结构)

目的：

1、提高查询效率
2、为字段排序

缺点：

降低了insert、update、delete的速度。因为不仅仅要保存数据，还要更新索引。

索引分类

单值索引：

一个索引是一个单列（数据库表中的一列），一个表中可以有多个单列索引。

唯一索引：

索引列的值必须唯一,但可以为null。

复合索引：

一个索引包含了多个列。

索引性能分析（explain）

索引性能分析离不开explain语句，具体语法如下：

Explain select * from table where columns= xxxx;

返回结果是一张列表：

id	select_type	table	type	possible_keys	key	keylen	ref	rows	extra

id
代表表的读取顺序，一个查询语句可能会联合多张表进行查询，此时id代表MySQL加载表的先后顺序。id为为数值类型，数值越大代表优先级越高，则越先加载。当数值相同时，代表优先级相同，加载顺序为列表的显示顺序。

select_type
表示查询类型。具体有如下类型：
SIMPLE：普通查询即简单的select查询，查询中不包含子查询或者UNION查询。

PRIMARY：在嵌套查询中，最外层的查询会被标记为PRIMARY。

SUBQUERY：与PRIMARY相对的，在嵌套查询的内层会被标记为SUBQUERY。注意，这里的SUBQUERY的子查询是不能在from语句后面的查询。

SELECT *
FROM `student`
WHERE id = (SELECT id
FROM class
WHERE name = '二班');

在上面查询中，where后面的的查询语句就会被标记成SUBQUERY。

DERIVED：同样也是标记子查询的符号，但与SUBQUERY不同的是，DERIVED标记的查询是在from语句后面的。from语句后面的表会有笛卡尔积的操作，因此，MySQL要递归的执行这些子查询，把结果放在临时表里。

SELECT t2.*
FROM (
SELECT t3.id
FROM  t3
WHERE t3.other_column = '123'
)s1, t2
WHERE s1.id = t2.id;

table
这一行是显示关于哪一张表的。

type
type表示查询使用了何种类型。有以下类型（从左至右越来越差）：

System	const	eq_ref	ref	range	index	All

System：表示表只有一行
const：常量连接，表最多只有一行匹配，通用用于主键或者唯一索引比较时。即将一个主键放置到where后面作为条件查询，mysql优化器就能把这次查询优化转化为一个常量。
eq_ref：唯一性索引扫描。对于每隔索引建，表中只有一条记录与之匹配。
ref：非唯一性索引扫描，表中可能有多个几路与之匹配。
range：给定范围检索，就是检索中where语句中的 between，in ，<，>等
index：遍历整个索引数扫描
All：全表遍历。
注意： 虽然index和All都是全表遍历，但是index是在索引中读取，All是在硬盘中读取。

possible keys
显示在这次查询过程中可能用到的索引

key
实际用到的索引。

keylen
索引使用的字节数。

ref
显示索引的哪一列被使用了，可能是一个常数。你写列或者常量被用于查找索引上的值。

rows
MySQL 查询优化器根据统计信息，估算 SQL 要查找到结果集需要扫描读取的数据行数。这个值非常直观显示 SQL 的效率好坏， 原则上 rows 越少越好。

extra
using filesort：说明MySQL会使用一个外部索引排序。而不是按照表内的索引进行读取。这种操作性能差，实际应该尽量避免。
using temporary：表示MySQL需要使用临时表来存储结果集，出现此情况性能也会打折扣。
using index：表示使用到了覆盖索引，覆盖索引指的是在一次查询中仅仅查询索引就能得到待查询的字段，而不需要访问表。即索引列包含了待查询列。
using where：表示使用到了where条件。

索引优化

单表情况

建表如下（图为article表）：

现要查询category_id为1，且comments大于1的情况下，views最多的article。查询语句如下：

SELECT id,author_id
FROM `article`
WHERE category_id = 1 AND comments > 1
ORDER BY views DESC
LIMIT 1;

使用explain来检测上面的查询语句得：

该语句出现了全表扫描All，和文件外部排序using filesort。这样的语句对数据库查询性能是大打折扣的，因此要将该语句优化。具体怎么优化呢？这里就是要建立索引了。
可以看到，这里的帅选条件是category_id，comments和views。那么常理来说应该将这三个按照语句中的出现顺序建立复合索引。但是，由于comments的帅选条件是大于，是一个范围。如果将它建立索引的话，它后面的索引将会失效， 也就是说建立了category_id，comments和views的复合索引，但实际只会用到category_id和comments，views会失效。因此在此仅仅建立category_id和views的复合索引。建立索引后再用explain分析上述查询语句。结果如下：

双表情况

有如下两个表（student表和class表）：

内连接

若使用内连接，则SQL语句如下：

SELECT * FROM student INNER JOIN class
ON student.class_id = class.id

对此语句的分析结果如下：

在此处对student的class_id 添加索引即可。

左外连接

SQL语句如下：

SELECT * FROM student LEFT JOIN class
ON student.class_id = class.id

此时没有任何索引，性能肯定不佳。左外连接的索引要建立在left join后的表上的相关列。在这个查询语句中，索引就应该就立在class表的id列。建立索引后执行查询分析可得下图：

索引优化法则（技巧）

1.尽量全值匹配

全值匹配，意思就是索引建啥我查啥。例如建立索引：

CREATE index idx_nap ON staffs(name,age,position);

那么根据全值匹配法则，下列语句是较优的：

SELECT name FROM staffs WHERE name = 'sam';
SELECT name,age FROM staffs WHERE name = 'sam' AND age = 23;
SELECT name,age,position FROM staffs WHERE name = 'sam' AND age = 23 AND position = 'CEO';

在此法则下，不管是待查询的列（select后的语句），还是检索条件（where后的语句），所涉及的列都是索引中的列。

2.最佳左前缀法则

以上面的索引为例，建立的复合索引顺序是name,age,position。就像是开火车一样，name是车头，name不在后面的车厢就不会起作用。同样的，age若不在，就会只剩车头name，position会作为车尾与火车脱节。因此以下的查询会有一个或者多个索引失效（注意：最后一个索引有效）：

SELECT name FROM staffs WHERE age = 23; //索引失效
SELECT name FROM staffs WHERE position = 'CEO'; //索引失效
SELECT age,position FROM staffs WHERE age = 23 AND position = 'CEO'; //索引失效
SELECT name,position FROM staffs WHERE name = 'sam' AND position = 'CEO'; //name索引生效，position索引失效
SELECT name,age,position FROM `staffs` WHERE age = 23 AND name = 'sam' AND position = 'CEO'//使用到索引，where后面顺序可以颠倒。

3.不在建索引的列上做任何操作

接上表staffs可知，单独为name建立一个索引。那么下列语句会使用到索引

SELECT * FROM staffs WHERE name = 'sam';

如果将其中where语句后面的条件改为如下语句时，索引则会失效。

SELECT name FROM staffs WHERE LEFT(name,3) = 'sam'; //匹配name字段左边三个字符符合sam的所有行

4.范围条件右边的索引会失效

同样是staffs表，建立的复合索引顺序是name,age,position。如下语句则会使用到索引：

SELECT name,age,position FROM staffs WHERE name = 'sam' AND age = 23 AND position = 'CEO';

但是，将age条件改为>23，那么age后的position索引会失效。

SELECT name,age,position FROM staffs WHERE name = 'sam' AND age > 23 AND position = 'CEO';

在上面SQL中，name列的索引被用于查找，age列的索引被用于排序。而position列的索引会失效。

5.尽量使用覆盖索引

同第一条法则

6.MySQL在使用!=或者<>会导致索引失效

不解释，简单。

7.is null和is not null无法使用索引

使用staffs表，建立name单值索引。

SELECT name FROM staffs WHERE name IS NULL;
SELECT name FROM staffs WHERE name IS NOT NULL;

8.like以通配符%开头会导致索引失效

使用staffs表，建立name单值索引。以下语句会使索引失效。

SELECT name FROM staffs WHERE name LIKE '%sa%';
SELECT name FROM staffs WHERE name LIKE '%sa';

对第一句使用explain查询得到分析结果如下：

可见，使用到了全表扫描。但是在具体业务逻辑中有时必须要用到%xxx%的查询条件，那么该如何优化呢？解决方案是建立与name相关联的复合索引，并使用覆盖索引查询（即查询字段被复合索引包括且符合最佳左前缀法则）。这里建立name，age复合索引。此时执行上面的查询语句得到如下结果：

可见，由全表扫描变为了全索引扫描，在性能上比全表扫描好了许多。

9.字符串不加引号索引失效

使用staffs表，建立name单值索引，在针对name进行查询时候，如下语句会导致索引失效：

SELECT name,age,position FROM staffs WHERE name = sam

该语句能够正确查询出结果，是因为MySQL内部会为sam字段做了类型转换。而恰恰是类型转换会使索引失效。所以记得加上引号。

10.用or关键词会使得索引失效

SELECT name,age,position FROM staffs WHERE name = 'sam' or name = 'lisa';