漫漫长路,其修远兮!
分类: Mysql/postgreSQL
2014-04-29 18:21:35
前段时间参加了Mysql索引与sql调优培训,自己线下摸索实践学习了下,这里总结几点分享给大家。顺便巩固下自己所学:)
一、单列索引和组合索引(也叫复合索引)的选择效率问题
先阐述下单列索引和组合索引的概念:
单列索引:即一个索引只包含单个列,一个表可以有多个单列索引,但这不是组合索引。
组合索引:即一个索包含多个列。
如果我们的查询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这三个列上的多列索引。
二、谨防最左前缀索引失效问题
继续考虑前面的例子,现在我们有一个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查看索引使用情况,下面第二节继续展开说,先到这吧休息会儿。。。。呵呵