MySQL数据库优化概述二_MySQL

　　EXPLAIN 语句可以被当作 DESCRIBE 的同义词来用，也可以用来获取一个MySQL要执行的 SELECT 语句的相关信息。EXPLAIN tbl_name 语法和 DESCRIBE tbl_name 或 SHOW COLUMNS FROM tbl_name 一样。
　　ref_or_null
　　这种连接类型类似 ref，不同的是MySQL会在检索的时候额外的搜索包含 NULL 值的记录。这种连接类型的优化是从MySQL 4.1.1开始的，它经常用于子查询。在以下的例子中，MySQL使用 ref_or_null 类型来处理 ref_table：

　　SELECT * FROM ref_table
　　WHERE key_column=expr OR key_column IS NULL;

　　index_merge
　　这种连接类型意味着使用了 Index Merge 优化方法。这种情况下，key字段包括了所有使用的索引，key_len 包括了使用的键的最长部分。详情请看"7.2.5 How MySQL Optimizes OR Clauses"。

　　unique_subquery
　　这种类型用例如一下形式的 IN 子查询来替换 ref：

　　value IN (SELECT primary_key FROM single_table WHERE some_expr)

　　unique_subquery 只是用来完全替换子查询的索引查找函数效率更高了。

　　index_subquery
　　这种连接类型类似 unique_subquery。它用子查询来代替 IN，不过它用于在子查询中没有唯一索引的情况下，例如以下形式：

　　value IN (SELECT key_column FROM single_table WHERE some_expr)

　　range
　　只有在给定范围的记录才会被取出来，利用索引来取得一条记录。key 字段表示使用了哪个索引。key_len 字段包括了使用的键的最长部分。这种类型时 ref 字段值是 NULL。range 用于将某个字段和一个定植用以下任何操作符比较时 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, 或 IN
　SELECT * FROM tbl_name
　　WHERE key_column = 10;
　　SELECT * FROM tbl_name
　　WHERE key_column BETWEEN 10 and 20;
　　SELECT * FROM tbl_name
　　WHERE key_column IN (10,20,30);
　　SELECT * FROM tbl_name
　　WHERE key_part1= 10 AND key_part2 IN (10,20,30);

　　index
　　连接类型跟 ALL 一样，不同的是它只扫描索引树。它通常会比 ALL 快点，因为索引文件通常比数据文件小。MySQL在查询的字段知识单独的索引的一部分的情况下使用这种连接类型。

　　ALL
　　将对该表做全部扫描以和从前一个表中取得的记录作联合。这时候如果第一个表没有被标识为 const 的话就不大好了，在其他情况下通常是非常糟糕的。正常地，可以通过增加索引使得能从表中更快的取得记录以避免 ALL。

　　possible_keys

　　possible_keys 字段是指MySQL在搜索表记录时可能使用哪个索引。注意，这个字段完全独立于 EXPLAIN 显示的表顺序。这就意味着 possible_keys 里面所包含的索引可能在实际的使用中没用到。如果这个字段的值是 NULL，就表示没有索引被用到。这种情况下，就可以检查 WHERE 子句中哪些字段那些字段适合增加索引以提高查询的性能。就这样，创建一下索引，然后再用 EXPLAIN 检查一下。详细的查看章节"14.2.2 ALTER TABLE Syntax"。想看表都有什么索引，可以通过 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 也是一样的效果。详细的可以查看章节"14.5.2.1 ANALYZE TABLE Syntax"和"5.7.2 Table Maintenance and Crash Recovery"。

　　key_len

　　key_len 字段显示了MySQL使用索引的长度。当 key 字段的值为 NULL 时，索引的长度就是 NULL。注意，key_len 的值可以告诉你在联合索引中MySQL会真正使用了哪些索引。

　　ref

　　ref 字段显示了哪些字段或者常量被用来和 key 配合从表中查询记录出来
rows

　　rows 字段显示了MySQL认为在查询中应该检索的记录数。

　　Extra

　　本字段显示了查询中MySQL的附加信息。以下是这个字段的几个不同值的解释：

　　Distinct

　　MySQL当找到当前记录的匹配联合结果的第一条记录之后，就不再搜索其他记录了。

　　Not exists

　　MySQL在查询时做一个 LEFT JOIN 优化时，当它在当前表中找到了和前一条记录符合 LEFT JOIN 条件后，就不再搜索更多的记录了。下面是一个这种类型的查询例子：

　　SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
　　WHERE t2.id IS NULL;

　　假使 t2.id 定义为 NOT NULL。这种情况下，MySQL将会扫描表 t1 并且用 t1.id 的值在 t2 中查找记录。当在 t2 中找到一条匹配的记录时，这就意味着 t2.id 肯定不会都是 NULL，就不会再在 t2 中查找相同 id 值的其他记录了。也可以这么说，对于 t1 中的每个记录，MySQL只需要在 t2 中做一次查找，而不管在 t2 中实际有多少匹配的记录。

　　range checked for each record (index map: #)

　　MySQL没找到合适的可用的索引。取代的办法是，对于前一个表的每一个行连接，它会做一个检验以决定该使用哪个索引(如果有的话)，并且使用这个索引来从表里取得记录。这个过程不会很快，但总比没有任何索引时做表连接来得快。

　　Using filesort

　　MySQL需要额外的做一遍从而以排好的顺序取得记录。排序程序根据连接的类型遍历所有的记录，并且将所有符合 WHERE 条件的记录的要排序的键和指向记录的指针存储起来。这些键已经排完序了，对应的记录也会按照排好的顺序取出来。详情请看"7.2.9 How MySQL Optimizes ORDER BY"。

　　Using index

　　字段的信息直接从索引树中的信息取得，而不再去扫描实际的记录。这种策略用于查询时的字段是一个独立索引的一部分。

　　Using temporary

　　MySQL需要创建临时表存储结果以完成查询。这种情况通常发生在查询时包含了GROUP BY 和 ORDER BY 子句，它以不同的方式列出了各个字段