MYSQL索引使用（一）
时间：2008-12-10
作者：stef_wu
出处：www.easyjf.com
数据库中经常被检索的表，一般都设置索引，这样有利于查询效率的提高，特别是海量数据，下面本文将详细介绍索引在Mysql中的使用！
什么是索引？
索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。 如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。 如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比 顺序扫描记录快100倍。
索引的类型：
普通索引：这是最基本的索引类型，没唯一性之类的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。
主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。
全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。
单列索引和多列索引
索引可以是单列索引，也可以是多列索引。对相关列使用索引是提高SELECT操作性能的最佳途径。
多列索引：
MySQL可以为多个列创建索引。一个索引可以包括15个列。对于某些列类型，可以索引列的前缀。
多列索引可以视为包含通过连接索引列的值而创建的值的排序的数组。
MySQL按这样的方式使用多列索引：当你在WHERE子句中为索引的第1个列指定已知的数量时，查询很快，即使你没有指定其它列的值。
假定表具有下面的结构：
CREATE TABLE test ( id INT NOT NULL,
last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name));
name索引是一个对last_name和first_name的索引。索引可以用于为last_name，或者为last_name和first_name在已知范围内指定值的查询。因此，name索引用于下面的查询：
SELECT * FROM test WHERE last_name='Widenius'; SELECT * FROM test WHERE last_name='Widenius' AND first_name='Michael'; SELECT * FROM test WHERE last_name='Widenius' AND (first_name='Michael' OR first_name='Monty'); SELECT * FROM test WHERE last_name='Widenius' AND first_name >='M' AND first_name < 'N';
然而，name索引不用于下面的查询：
SELECT * FROM test WHERE first_name='Michael'; SELECT * FROM test WHERE last_name='Widenius' OR first_name='Michael';
MYSQL如果使用索引(from mysql reference)
索引用于快速找出在某个列中有一特定值的行。不使 用索引，MySQL必须从第1条记录开始然后读完整个表直到找出相关的行。表越大，花费的时间越多。如果表中查询的列有一个索引，MySQL能快速到达一 个位置去搜寻到数据文件的中间，没有必要看所有数据。如果一个表有1000行，这比顺序读取至少快100倍。注意如果你需要访问大部分行，顺序读取要快得 多，因为此时我们避免磁盘搜索。
大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B树中存储。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。
字符串自动地压缩前缀和结尾空格。
总的来说，按后面的讨论使用索引。本节最后描述hash索引(用于MEMORY表)的特征。
索引用于下面的操作：
· 快速找出匹配一个WHERE子句的行。
· 删除行。如果可以在多个索引中进行选择，MySQL通常使用找到最少行的索引。
· 当执行联接时，从其它表检索行。
· 对具体有索引的列key_col找出MAX()或MIN()值。由预处理器进行优化，检查是否对索引中在key_col之前发生所有关键字元素使用了WHERE key_part_# = constant。在这种情况下，MySQL为每个MIN()或MAX()表达式执行一次关键字查找，并用常数替换它。如果所有表达式替换为常量，查询立即返回。例如：
· SELECT MIN(key_part2),MAX(key_part2) FROM tbl_name WHERE key_part1=10;
· 如果对一个可用关键字的最左面的前缀进行了排序或分组(例如，ORDER BY key_part_1,key_part_2)，排序或分组一个表。如果所有关键字元素后面有DESC，关键字以倒序被读取。参见7.2.12节，“MySQL如何优化ORDER BY”。
· 在一些情况中，可以对一个查询进行优化以便不用查询数据行即可以检索值。如果查询只使用来自某个表的数字型并且构成某些关键字的最左面前缀的列，为了更快，可以从索引树检索出值。
· SELECT key_part3 FROM tbl_name· WHERE key_part1=1
假定你执行下面的SELECT语句：
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
如果col1和col2上存在一个多列索引，可以直接取出相应行。如果col1和col2上存在单列索引，优化器试图通过决定哪个索引将找到更少的行来找出更具限制性的索引并且使用该索引取行。
如果表有一个多列索引，优化器可以使用最左面的索引前缀来找出行。例如，如果有一个3列索引(col1,col2,col3)，则已经对(col1)、(col1,col2)和(col1,col2,col3)上的搜索进行了索引。
如果列不构成索引最左面的前缀，MySQL不能使用局部索引。假定有下面显示的SELECT语句：
SELECT * FROM tbl_name WHERE col1=val1;SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2; SELECT * FROM tbl_name WHERE col2=val2;SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;
如果 (col1，col2，col3)有一个索引，只有前2个查询使用索引。第3个和第4个查询确实包括索引的列，但(col2)和(col2，col3)不是 (col1，col2，col3)的最左边的前缀。
也可以在表达式通过=、>、>=、<、<=或者BETWEEN操作符使用B-树索引进行列比较。如果LIKE的参数是一个不以通配符开头的常量字符串，索引也可以用于LIKE比较。例如，下面的SELECT语句使用索引：
SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
在第1个语句中，只考虑带'Patrick' <=key_col < 'Patricl'的行。在第2个语句中，只考虑带'Pat' <=key_col < 'Pau'的行。
下面的SELECT语句不使用索引：
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%'; SELECT * FROM tbl_name WHERE key_col LIKE other_col;
在第一条语句中，LIKE值以一个通配符字符开始。在第二条语句中，LIKE值不是一个常数。
如果使用... LIKE '%string%'并且string超过3个字符，MySQL使用Turbo Boyer-Moore算法初始化字符串的模式然后使用该模式来更快地进行搜索。
如果col_name被索引，使用col_name IS NULL的搜索将使用索引。
任何不跨越WHERE子句中的所有AND级的索引不用于优化查询。换句话说，为了能够使用索引，必须在每个AND组中使用索引前缀。
下面的WHERE子句使用索引：
... WHERE index_part1=1 AND index_part2=2 AND other_column=3 /* index = 1 OR index = 2 */ ... WHERE index=1 OR A=10 AND index=2 /* optimized like "index_part1='hello'" */ ... WHERE index_part1='hello' AND index_part3=5 /* Can use index on index1 but not on index2 or index3 */ ... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;
下面的WHERE子句不使用索引：
/* index_part1 is not used */ ... WHERE index_part2=1 AND index_part3=2 /* Index is not used in both parts of the WHERE clause */ ... WHERE index=1 OR A=10 /* No index spans all rows */ ... WHERE index_part1=1 OR index_part2=10
有时MySQL不使用索引，即使有可用的索引。一 种情形是当优化器估计到使用索引将需要MySQL访问表中的大部分行时。(在这种情况下，表扫描可能会更快些，因为需要的搜索要少）。然而，如果此类查询 使用LIMIT只搜索部分行，MySQL则使用索引，因为它可以更快地找到几行并在结果中返回。
Hash索引还有一些其它特征：
· 它们只用于使用=或<=>操作符的等式比较(但很快)。它们用于比较 操作符，例如发现范围值的<。
· 优化器不能使用hash索引来加速ORDER BY操作。(该类索引不能用来按顺序搜索下一个条目）。
· MySQL不能确定在两个值之间大约有多少行(这被范围优化器用来确定使用哪个索引)。如果你将一个MyISAM表改为hash-索引的MEMORY表，会影响一些查询。
· 只能使用整个关键字来搜索一行。(用B-树索引，任何关键字的最左面的前缀可用来找到行）。
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，说明使用了排序和限制条件。
再执行一次查询，输出为：
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，说明使用了排序和限制条件。