MySQL 索引详解
一、单列索引和组合索引(也叫复合索引)的选择效率问题
先阐述下单列索引和组合索引的概念:
单列索引:即一个索引只包含单个列,一个表可以有多个单列索引,但这不是组合索引。
组合索引:即一个索包含多个列。
如果我们的查询where条件只有一个,我们完全可以用单列索引,这样的查询速度较快,索引也比较瘦身。如果我们的业务场景是需要经常查询多个组合列,不要试图分别基于单个列建立多个单列索引。这是因为当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这三个列上的多列索引。 </p> </span>
二、谨防最左前缀索引失效问题
继 续考虑前面的例子,现在我们有一个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"; |
这里我特地实践了下:
执行结果如下:
可以看出这里最左前缀索引失效了。这里没有用到索引直接全表扫描了。
我们再看下如果这样呢?
执行结果如下:
可见还是用到了索引,不是应该失效吗?是不是有点迷糊了?
特地请教了DBA玄惭大师,这里只是最左前缀索引失效,但是不代表整个索引失效,只是效率没有那么高了。最左前缀索引的效率是比较高的。本来我误以为只要第一个查询字段不是组合索引的最左前缀索引字段整个索引会失效,其实不然。
这里强调下只是最有效率的最左前缀索引失效不是整个索引失效。
三、使用explain分析索引
在 不确定应该在哪些数据列上创建索引的时候,我们可以从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键 字,MySQL将不是去执行那条SELECT命令,而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出 来。这里我基本阐述下每个信息字段含义,不展开阐述,我们只要注意几个关键点(关键点以下用红色加粗显示)能大概看懂即可呵呵~~
1.id:SQL执行的顺利的标识。
sql从里向外执行,通过以上观察发现sql是按照id从大到小执行的。
2.select_type:SELECT类型
1)简单SELECT(不使用UNION或子查询等)
2) PRIMARY:最外层的select
3)DERIVED:派生表的SELECT(FROM子句的子查询)
4)UNION:UNION中的第二个或后面的SELECT语句
5)UNION RESULT:UNION的结果。
6)DEPENDENT UNION:UNION中的第二个或后面的SELECT语句,取决于外面的查询
7)SUBQUERY:子查询中的第一个SELECT
8)DEPENDENT SUBQUERY:子查询中的第一个SELECT,取决于外面的查询
PS:这里我总结了下子查询的in语句会用到DEPENDENT关键字,如果子查询是union则是DEPENDENT UNION;如果子查询是简单的条件语句则是DEPENDENT SUBQUERY。这里不一定准确是我自己总结的哈~~如果不对望指正
3.table:表的名字。
有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
4.type:连接操作的类型。
这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中,效率最高的是system,然后依次是const、eq_ref、ref、range、index和 All。一般来说,得保证查询至少达到range级别,最好能达到ref,否则就可能会出现性能问题。
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少(越少越好)