MYSQL索引使用（二） - 数据库 - 技术文章

MYSQL索引使用（二）

时间：2008-12-10 作者：佚名出处：互联网

数据库中经常被检索的表，一般都设置索引，这样有利于查询效率的提高，特别是海量数据，下面本文将详细介绍索引在Mysql中的使用！

EXPLAIN使用方法

EXPLAIN tbl_name

或：

EXPLAIN [EXTENDED] SELECT select_options

EXPLAIN语句可以用作DESCRIBE的一个同义词，或获得关于MySQL如何执行SELECT语句的信息：

· EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。

· 如果在SELECT语句前放上关键词EXPLAIN，MySQL将解释它如何处理SELECT，提供有关表如何联接和联接的次序。

该节解释EXPLAIN的第2个用法。

借助于EXPLAIN，可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快的SELECT。

如果由于使用不正确的索引出现了问题，应运行ANALYZE TABLE更新表的统计（例如关键字集的势），这样会影响优化器进行的选择。

还可以知道优化器是否以一个最佳次序联接表。为了强制优化器让一个SELECT语句按照表命名顺序的联接次序，语句应以STRAIGHT_JOIN而不只是SELECT开头。

EXPLAIN为用于SELECT语句中的每个表返回一行信息。表以它们在处理查询过程中将被MySQL读入的顺序被列出。MySQL用一遍扫描多次联接（single-sweep multi-join）的方式解决所有联接。这意味着MySQL从第一个表中读一行，然后找到在第二个表中的一个匹配行，然后在第3个表中等等。当所有的表处理完后，它输出选中的列并且返回表清单直到找到一个有更多的匹配行的表。从该表读入下一行并继续处理下一个表。

当使用EXTENDED关键字时，EXPLAIN产生附加信息，可以用SHOW WARNINGS浏览。该信息显示优化器限定SELECT语句中的表和列名，重写并且执行优化规则后SELECT语句是什么样子，并且还可能包括优化过程的其它注解。

EXPLAIN的每个输出行提供一个表的相关信息，并且每个行包括下面的列：

· id

SELECT识别符。这是SELECT的查询序列号。

· select_type

SELECT类型，可以为以下任何一种：

o SIMPLE

简单SELECT(不使用UNION或子查询)

o PRIMARY

最外面的SELECT

o UNION

UNION中的第二个或后面的SELECT语句

o DEPENDENT UNION

UNION中的第二个或后面的SELECT语句，取决于外面的查询

o UNION RESULT

UNION的结果。

o SUBQUERY

子查询中的第一个SELECT

o DEPENDENT SUBQUERY

子查询中的第一个SELECT，取决于外面的查询

o DERIVED

导出表的SELECT(FROM子句的子查询)

· table

输出的行所引用的表。

· type

联接类型。下面给出各种联接类型，按照从最佳类型到最坏类型进行排序：

o system

表仅有一行(=系统表)。这是const联接类型的一个特例。

o const

表最多有一个匹配行，它将在查询开始时被读取。因为仅有一行，在这行的列值可被优化器剩余部分认为是常数。const表很快，因为它们只读取一次！

const用于用常数值比较PRIMARY KEY或UNIQUE索引的所有部分时。在下面的查询中，tbl_name可以用于const表：

SELECT * from tbl_name WHERE primary_key=1； 
SELECT * from tbl_name WHERE primary_key_part1=1 and  primary_key_part2=2；

o eq_ref

对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的联接类型，除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。

eq_ref可以用于使用= 操作符比较的带索引的列。比较值可以为常量或一个使用在该表前面所读取的表的列的表达式。

在下面的例子中，MySQL可以使用eq_ref联接来处理ref_tables：

o ref

对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀，或如果键不是UNIQUE或PRIMARY KEY（换句话说，如果联接不能基于关键字选择单个行的话），则使用ref。如果使用的键仅仅匹配少量行，该联接类型是不错的。

ref可以用于使用=或<=>操作符的带索引的列。

在下面的例子中，MySQL可以使用ref联接来处理ref_tables：

SELECT * FROM ref_table WHERE key_column=expr; 
SELECT * FROM ref_table,other_table  WHERE ref_table.key_column=other_table.column; 
SELECT * FROM ref_table,other_table  WHERE ref_table.key_column_part1=other_table.column    AND 
ref_table.key_column_part2=1;

o ref_or_null

该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行。在解决子查询中经常使用该联接类型的优化。

在下面的例子中，MySQL可以使用ref_or_null联接来处理ref_tables：

SELECT * FROM ref_tableWHERE key_column=expr OR key_column IS NULL;

o index_merge

该联接类型表示使用了索引合并优化方法。在这种情况下，key列包含了使用的索引的清单，key_len包含了使用的索引的最长的关键元素。

o unique_subquery

该类型替换了下面形式的IN子查询的ref：

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery是一个索引查找函数，可以完全替换子查询，效率更高。

o index_subquery

该联接类型类似于unique_subquery。可以替换IN子查询，但只适合下列形式的子查询中的非唯一索引：

value IN (SELECT key_column FROM single_table WHERE some_expr)

o range

只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。key_len包含所使用索引的最长关键元素。在该类型中ref列为NULL。

当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较关键字列时，可以使用range：

SELECT * FROM tbl_nameWHERE key_column = 10; 
SELECT * FROM tbl_nameWHERE key_column BETWEEN 10 and 20; 
SELECT * FROM tbl_nameWHERE key_column IN (10,20,30); 
SELECT * FROM tbl_nameWHERE key_part1= 10 AND key_part2 IN (10,20,30);

o index

该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小。

当查询只使用作为单索引一部分的列时，MySQL可以使用该联接类型。

o ALL

对于每个来自于先前的表的行组合，进行完整的表扫描。如果表是第一个没标记const的表，这通常不好，并且通常在它情况下很差。通常可以增加更多的索引而不要使用ALL，使得行能基于前面的表中的常数值或列值被检索出。

· possible_keys

possible_keys列指出MySQL能使用哪个索引在该表中找到行。注意，该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。

如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询。

为了看清一张表有什么索引，使用SHOW INDEX FROM tbl_name。

· key

key列显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

对于MyISAM和BDB表，运行ANALYZE TABLE可以帮助优化器选择更好的索引。对于MyISAM表，可以使用myisamchk --analyze。

· key_len

key_len列显示MySQL决定使用的键长度。如果键是NULL，则长度为NULL。注意通过key_len值我们可以确定MySQL将实际使用一个多部关键字的几个部分。

· ref

ref列显示使用哪个列或常数与key一起从表中选择行。

· rows

rows列显示MySQL认为它执行查询时必须检查的行数。

· Extra

该列包含MySQL解决查询的详细信息。下面解释了该列可以显示的不同的文本字符串：

o Distinct

MySQL发现第1个匹配行后，停止为当前的行组合搜索更多的行。

o Not exists

MySQL能够对查询进行LEFT JOIN优化，发现1个匹配LEFT JOIN标准的行后，不再为前面的的行组合在该表内检查更多的行。

下面是一个可以这样优化的查询类型的例子：

SELECT * 从t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL；

假定t2.id定义为NOT NULL。在这种情况下，MySQL使用t1.id的值扫描t1并查找t2中的行。如果MySQL在t2中发现一个匹配的行，它知道t2.id绝不会为 NULL，并且不再扫描t2内有相同的id值的行。换句话说，对于t1的每个行，MySQL只需要在t2中查找一次，无论t2内实际有多少匹配的行。

o range checked for each record (index map: #)

MySQL没有发现好的可以使用的索引，但发现如果来自前面的表的列值已知，可能部分索引可以使用。对前面的表的每个行组合，MySQL检查是否可以使用range或index_merge访问方法来索取行。

这并不很快，但比执行没有索引的联接要快得多。

o Using filesort

MySQL需要额外的一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行。

o Using index

从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息。当查询只使用作为单一索引一部分的列时，可以使用该策略。

o Using temporary

为了解决查询，MySQL需要创建一个临时表来容纳结果。典型情况如查询包含可以按不同情况列出列的GROUP BY和ORDER BY子句时。

o Using where

WHERE子句用于限制哪一个行匹配下一个表或发送到客户。除非你专门从表中索取或检查所有行，如果Extra值不为Using where并且表联接类型为ALL或index，查询可能会有一些错误。

如果想要使查询尽可能快，应找出Using filesort 和Using temporary的Extra值。

o Using sort_union(...), Using union(...), Using intersect(...)

这些函数说明如何为index_merge联接类型合并索引扫描。

o Using index for group-by

类似于访问表的Using index方式，Using index for group-by表示MySQL发现了一个索引，可以用来查询GROUP BY或DISTINCT查询的所有列，而不要额外搜索硬盘访问实际的表。并且，按最有效的方式使用索引，以便对于每个组，只读取少量索引条目。

通过相乘EXPLAIN输出的rows列的所有值，你能得到一个关于一个联接如何的提示。这应该粗略地告诉你MySQL必须检查多少行以执行查询。当你使用max_join_size变量限制查询时，也用这个乘积来确定执行哪个多表SELECT语句。

下面通过一个列子来演示通过索引来优化查询：

开发环境：JPA(HIBERNATE)+SPRING+EASYJWEB

我的本本配置：

1年半前的啦～

看看当前的内存状态：

首先准备NewsDoc对象，该对象定义：

@Entity
public class NewsDoc implements ReviewEnabled, TagEnabled, SearchIndexEnabled,Serializable {
 @Id
 @GeneratedValue(strategy = GenerationType.TABLE)
 private Long id;
 @Column(length = 100)
 private String title;// 文章标题
 @Column(length = 100)
 private String subTitle;// 副标题
 @javax.persistence.Basic(optional = false)
 @javax.persistence.ManyToOne
 private NewsDir dir;// 文章目录
 private Date displayTime;// 文章显示日期
 @javax.persistence.Lob
 @javax.persistence.Basic(fetch = javax.persistence.FetchType.LAZY)
 private String content;// 文章内容
 @Column(length = 200)
 private String dirPath;// 文章目录路径
 private Integer readTimes = 0;// 阅读次数
 private Integer reviewTimes = 0;// 评论次数
 private Date inputTime = new Date();// 输入时间
 private Boolean elite = false;// 精华文章
 private Boolean auditing = true;// 审核文章
 private Integer status = 0;// 正常=0、锁定=1、删除=-1
 ......getter and setter
}

省略了一些其他的属性。

现在准备了23W条数据来演示一下查询：

现在NewsDoc对应的表当前的索引状态：

这里为几个简单的关联完成了索引。

现在来看看一个页面的查询及一个简单的查询统计：

查询：

$!NU.snq.dir("zixun").number(4).list

对应的HQL查询语句实际上是：

String hql="select NewsDoc obj from NewsDoc where obj.dirPath like ? And obj.auditing=? And 
obj.displayTime=? orderBy obj.displayTime";
Query query=em.createQuery(hql);
query.setParameter(1,"zixun@%");
query.setParameter(2,true);
query.setParameter(3,new Date());
query.setParameter(4,0);
query.setFirstResult(0);
query.setMaxResult(4);
Return query.getResultList();

打开Hibernate的showSql选项，并加上一个简单的查询时间输出，我们可以看到下面的查询语句及时间统计。

Hibernate: select newsdir0_.id as id42_, newsdir0_.sn as sn42_, newsdir0_.url as url42_, newsdir0_.title 
as title42_, newsdir0_.dirPath as dirPath42_, newsdir0_.types as types42_, newsdir0_.template_id as 
template12_42_, newsdir0_.status as status42_, newsdir0_.parent_id as parent11_42_, 
newsdir0_.description as descript8_42_, newsdir0_.sequence as sequence42_, newsdir0_.display as 
display42_ from NewsDir newsdir0_ where newsdir0_.sn=?

Hibernate: select newsdoc0_.id as id43_, newsdoc0_.title as title43_, newsdoc0_.subTitle as subTitle43_, 
newsdoc0_.dir_id as dir22_43_, newsdoc0_.contentTypes as contentT4_43_, newsdoc0_.url as url43_, 
newsdoc0_.displayTime as displayT6_43_, newsdoc0_.content as content43_, newsdoc0_.intro as intro43_, 
newsdoc0_.author_id as author23_43_, newsdoc0_.source_id as source24_43_, newsdoc0_.dirPath as 
dirPath43_, newsdoc0_.sequence as sequence43_, newsdoc0_.expiredTime as expired11_43_, 
newsdoc0_.readTimes as readTimes43_, newsdoc0_.reviewTimes as reviewT13_43_, newsdoc0_.inputTime
 as inputTime43_, newsdoc0_.template_id as template20_43_, newsdoc0_.owner_id as owner21_43_, 
newsdoc0_.elite as elite43_, newsdoc0_.auditing as auditing43_, newsdoc0_.status as status43_, 
newsdoc0_.updateTime as updateTime43_, newsdoc0_.topTime as topTime43_ from NewsDoc 
newsdoc0_ where 1=1 and (newsdoc0_.dirPath like ?) and newsdoc0_.auditing=1 and 
newsdoc0_.displayTime<=? and newsdoc0_.status>=0 order by newsdoc0_.displayTime desc limit ?, ?

Hibernate: select newsdir0_.id as id42_0_, newsdir0_.sn as sn42_0_, newsdir0_.url as url42_0_, 
newsdir0_.title as title42_0_, newsdir0_.dirPath as dirPath42_0_, newsdir0_.types as types42_0_, 
newsdir0_.template_id as template12_42_0_, newsdir0_.status as status42_0_, newsdir0_.parent_id as 
parent11_42_0_, 
newsdir0_.description as descript8_42_0_, newsdir0_.sequence as sequence42_0_, newsdir0_.display as 
display42_0_ from NewsDir newsdir0_ where newsdir0_.id=?
all query use 47828

第一个和第三个查询语句是查询出了一个关联的Dir对象，而中间的那个简单的SQL是查询的符合条件的4个文章对象，可以看到，耗时是惊人的47848毫秒！

我们将中间那条SQL直接放在Navicat中执行，并分析：

首先填完其中的参数，整个完整的SQL如下：

select newsdoc0_.id as id43_, newsdoc0_.title as title43_, newsdoc0_.subTitle as subTitle43_, 
newsdoc0_.dir_id as dir22_43_, newsdoc0_.contentTypes as contentT4_43_, newsdoc0_.url as url43_, 
newsdoc0_.displayTime as displayT6_43_, newsdoc0_.content as content43_, newsdoc0_.intro as 
intro43_, newsdoc0_.author_id as author23_43_, newsdoc0_.source_id as source24_43_, 
newsdoc0_.dirPath as dirPath43_, newsdoc0_.sequence as sequence43_, newsdoc0_.expiredTime as 
expired11_43_, newsdoc0_.readTimes as readTimes43_, newsdoc0_.reviewTimes as reviewT13_43_, 
newsdoc0_.inputTime as inputTime43_, newsdoc0_.template_id as template20_43_, newsdoc0_.owner_id as 
owner21_43_, newsdoc0_.elite as elite43_, newsdoc0_.auditing as auditing43_, newsdoc0_.status as
status43_, newsdoc0_.updateTime as updateTime43_, newsdoc0_.topTime as topTime43_ from NewsDoc 
newsdoc0_ where 1=1 and (newsdoc0_.dirPath like 'sqpd@zixun@%') and 
newsdoc0_.auditing=1 and newsdoc0_.displayTime<=now() and newsdoc0_.status>=0 order by 
newsdoc0_.displayTime desc limit 0, 4

在Navicat里面查询这条SQL也花了不少时间，现在来分析一下这个SQL，看看EXPLAIN的结果

对照前面对EXPLAIN的解释：

Id：1，Select的查询序号，没有什么作用。

Select_type：SIMPLE，简单的Select，并没有使用UNION或者任何子查询，这里说明，这条耗时漫长的SQL语句只是个简单的SELECT，

Table：Newsdoc0_，查询的是newsdoc表

Type：ALL，对于每个来自于先前的表的行组合，进行完整的表扫描。这个重要的参数表明，刚才的查询，扫描完了整个24W条数据。这个是影响性能的一个重要的因素。

Possible_keys为空，说明查询没有任何相关的索引。

Key为空，说明没有使用任何的索引。

Key_len为空，也是没有任何的索引造成的。

Rows为316779，说明MYSQL认为需要扫描31W条数据，才能完成查询。

Extra：Using where;Using filesort，说明使用了排序和限制条件。

要第一次的提高查询效率，我们分析SQL，发现用到了dirPath,auditing,status,displayTime这4个查询条件，那么，我们先为这4个属性建立单列索引：

再执行一次查询，输出为：

Hibernate: select newsdir0_.id as id42_, newsdir0_.sn as sn42_, newsdir0_.url as url42_, newsdir0_.title 
as title42_, newsdir0_.dirPath as dirPath42_, newsdir0_.types as types42_, newsdir0_.template_id as
 template12_42_, newsdir0_.status as status42_, newsdir0_.parent_id as parent11_42_, 
newsdir0_.description as descript8_42_, newsdir0_.sequence as sequence42_, newsdir0_.display 
as display42_ from NewsDir newsdir0_ where newsdir0_.sn=?

Hibernate: select newsdoc0_.id as id43_, newsdoc0_.title as title43_, newsdoc0_.subTitle as subTitle43_, 
newsdoc0_.dir_id as dir22_43_, newsdoc0_.contentTypes as contentT4_43_, newsdoc0_.url as url43_, 
newsdoc0_.displayTime as displayT6_43_, newsdoc0_.content as content43_, newsdoc0_.intro as intro43_, 
newsdoc0_.author_id as author24_43_, newsdoc0_.source_id as source23_43_, newsdoc0_.dirPath as 
dirPath43_, newsdoc0_.sequence as sequence43_, newsdoc0_.expiredTime as expired11_43_, 
newsdoc0_.readTimes as readTimes43_, newsdoc0_.reviewTimes as reviewT13_43_, newsdoc0_.inputTime
 as inputTime43_, newsdoc0_.template_id as template21_43_, newsdoc0_.owner_id as owner20_43_, 
newsdoc0_.elite as elite43_, newsdoc0_.auditing as auditing43_, newsdoc0_.status as status43_, 
newsdoc0_.updateTime as updateTime43_, newsdoc0_.topTime as topTime43_ from NewsDoc 
newsdoc0_ where 1=1 and (newsdoc0_.dirPath like ?) and newsdoc0_.auditing=1 and 
newsdoc0_.displayTime<=? and newsdoc0_.status>=0 order by newsdoc0_.displayTime desc limit ?, ?

Hibernate: select newsdir0_.id as id42_0_, newsdir0_.sn as sn42_0_, newsdir0_.url as url42_0_, 
newsdir0_.title as title42_0_, newsdir0_.dirPath as dirPath42_0_, newsdir0_.types as types42_0_, 
newsdir0_.template_id as template12_42_0_, newsdir0_.status as status42_0_, newsdir0_.parent_id as 
parent11_42_0_, newsdir0_.description as descript8_42_0_, newsdir0_.sequence as sequence42_0_, 
newsdir0_.display as 
display42_0_ from NewsDir newsdir0_ where newsdir0_.id=?
all query use 500

同样的查询，仅仅用了500ms，速度提高了95倍。

来看看对这条SQL执行EXPLAIN的结果：

同样来分析一下这个结果：

Id：1，Select的查询序号，没有什么作用。

Select_type：SIMPLE，简单的Select，并没有使用UNION或者任何子查询，这里说明，这条耗时漫长的SQL语句只是个简单的SELECT，

Table：Newsdoc0_，查询的是newsdoc表

Type：Range，只检索了指定的范围，这里使用的是dirpath作为范围查询条件

Possible_keys有INDEX_DIRPATH；INDEX_STATUS；INDEX_AUDITING；INDEX_DISPLAYTIME，即可以使用刚才创建的4个索引。

Key为INDEX_DIRPATH，MYSQL在使用索引优化查询时，会选择它认为可以过滤最多数据的那个索引，这里使用的是INDEX_DIRPATH，说明使用该索引，能通过dirpath这个属性，只扫描最少的数据行。

Key_len为603，使用的索引的长度为603。

Rows为286，说明MYSQL认为通过索引的过滤，只需要查询286条数据行即可完成查询。

Extra：Using where;Using filesort，说明使用了排序和限制条件。

网友留言/评论

我要留言/评论