一、先阐述下单列索引和组合索引的概念
单列索引：即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。
组合索引：即一个索包含多个列。
如果我们的查询where条件只有一个，我们完全可以用单列索引，这样的查询速度较快，索引也比较瘦身。如果我们的业务场景是需要经常查询多个组合列，不要试图分别基于单个列建立多个单列索引（因为虽然有多个单列索引，但是MySQL只能用到其中的那个它认为似乎最有效率的单列索引）。这是因为当SQL语句所查询的列，全部都出现在复合索引中时，此时由于只需要查询索引块即可获得所有数据，当然比使用多个单列索引要快得多。下面以实际例子说明：
举例：
以下是代码片段：
CREATE TABLE people (
peopleid SMALLINT NOT NULL AUTO_INCREMENT,
firstname CHAR(50) NOT NULL,
lastname CHAR(50) NOT NULL,
age SMALLINT NOT NULL,
townid SMALLINT NOT NULL,
PRIMARY KEY (peopleid)
);
下面是我们插入到这个people表的数据：
这个数据片段中有四个名字为“Mikes”的人(其中两个姓Sullivans，两个姓McConnells)，有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。
这个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid(SQL命令为SELECT peopleid FROM people WHERE firstname="Mike" AND lastname="Sullivan" AND age=17;)。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。
首先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引(ALTER TABLE people ADD INDEX firstname (firstname);)，MySQL将通过这个索引迅速把搜索范围限制到那些firstname="Mike"的记录，然后再在这个“中间结果集”上进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之后，MySQL就返回最终的搜索结果。
由于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相似。
为了提高搜索效率，我们需要考虑运用多列索引。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果!下面是创建这个多列索引的SQL命令：
以下是代码片段：
ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age);
由于索引文件以B+树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录!
那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。
二、谨防最左前缀索引失效问题
继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。为什么没有 (lastname,age)等这样的组合索引呢？这是因为 mysql 组合索引"最左前缀"（Leftmost Prefixing）的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引。
以下是代码片段：
# The following queries can use the Leftmost Prefixing index:
SELECT peopleid FROM people WHERE firstname="Mike" AND lastname="Sullivan" AND age="17";
SELECT peopleid FROM people WHERE firstname="Mike" AND lastname="Sullivan";
SELECT peopleid FROM people WHERE firstname="Mike";
# The following queries cannot use the Leftmost Prefixing index at all:
SELECT peopleid FROM people WHERE lastname="Sullivan";
SELECT peopleid FROM people WHERE age="17";
SELECT peopleid FROM people WHERE lastname="Sullivan" AND age="17";
这里我特地实践了下：
[图片上传失败...(image-fd474e-1583674549539)]
执行结果如下：
[图片上传失败...(image-58fad5-1583674549539)]
可以看出这里最左前缀索引失效了。这里没有用到索引直接全表扫描了。
我们再看下如果这样呢？
[图片上传失败...(image-e57d2c-1583674549539)]
执行结果如下：
[图片上传失败...(image-81c3ae-1583674549540)]
可见还是用到了索引，这里只是最左前缀索引失效，但是不代表整个索引失效，只是效率没有那么高了。最左前缀索引的效率是比较高的。本来我误以为只要第一个查询字段不是组合索引的最左前缀索引字段整个索引会失效，其实不然。这里强调下只是最有效率的最左前缀索引失效不是整个索引失效。
三、使用explain分析索引
在不确定应该在哪些数据列上创建索引的时候，我们可以从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出来。这里我基本阐述下每个信息字段含义，不展开阐述，我们只要注意几个关键点（关键点以下用红色加粗显示）能大概看懂即可呵呵~~
1、id:SQL执行的顺序的标识。
[图片上传失败...(image-6acea1-1583674549539)]
sql从里向外执行，通过以上观察发现sql是按照id从大到小执行的。
2、select_type: select类型
1)、SIMPLE(不使用UNION或子查询等)
[图片上传失败...(image-532c25-1583674549539)]
- 、PRIMARY：最外层的select
[图片上传失败...(image-b19c45-1583674549538)]
3）、DERIVED：派生表的SELECT(FROM子句的子查询)
[图片上传失败...(image-8a6b8d-1583674549539)]
[图片上传失败...(image-c3eff2-1583674549539)]
4）、UNION：UNION中的第二个或后面的SELECT语句
[图片上传失败...(image-2138e8-1583674549539)]
5）、UNION RESULT：UNION的结果。
[图片上传失败...(image-912683-1583674549539)]
[图片上传失败...(image-b3c4ba-1583674549539)]
6）、DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询
[图片上传失败...(image-dc22ed-1583674549539)]
7）、SUBQUERY：子查询中的第一个SELECT
[图片上传失败...(image-6de717-1583674549538)]
8）、DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询
[图片上传失败...(image-561a4e-1583674549538)]
3、table：表的名字。
有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
4、type：连接操作的类型。
这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中，效率最高的是system，然后依次是const、eq_ref、ref、range、index和 All。一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。
1）、system
表只有一行：system表。这是const连接类型的特殊情况
2）、const
表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
3）、eq_ref
在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
4）、ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少（越少越好）
5）、range
这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况
6）、index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
7）、ALL
这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。因为它要扫描整个表。你可以加入更多的索引来解决这个问题。
5、possible_key：MySQL在搜索数据记录时可以选用的各个索引名。
这里的索引名是创建索引时指定的索引昵称;如果索引没有昵称，则默认显示的是索引中第一个列的名字(在上一节举的例子中是“firstname”)。默认索引名字的含义往往不是很明显。
6、key：它显示了MySQL实际使用的索引。
key数据列是MySQL实际选用的索引，如果它为空(或NULL)，则MySQL不使用索引。
7、key_len：索引中被使用部分的长度，以字节计。
key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。 在上例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节（smallint存储大小为2字节）。如果MySQL只使用索引中的firstname部分，则key_len将是50。 在不损失精确性的情况下 ，key_len数据列里的值越小越好(意思是更快)。
8、ref：显示使用哪个列或常数与key一起从表中选择行。
ref数据列给出了关联关系中另一个数据表里的数据列的名字。
9、rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。
显然，这里最理想的数字就是1。
10、extra：附加信息
Using index和Using where会遇到的比较多，可以重点记下，其他的我没怎么遇到过了解即可，遇到具体问题可以查阅哈
1）、Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
2）、Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
3）、Range checked for each
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
4）、Using filesort
看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
5）Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
6）Using temporary
看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
7）Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题
-- 转载自：
https://blog.csdn.net/xtdhqdhq/article/details/17582779