mysql explain的用法(使用explain优化查询语句)
首先我来给一个简单的例子，然后再来解释explain列的信息。
表一：catefory 文章分类表：
create table if not exists `category` ( `id` smallint(5) unsigned not null auto_increment, `name` varchar(50) not null default '', primary key (`id`) ) engine=myisam insert into `test`.`category` values (null , '分类1'); insert into `test`.`category` values (null , '分类2'); insert into `test`.`category` values (null , '分类3');
表二：article文章表：
create table if not exists `article` (
`aid` int(11) not null,
`cid` int(11) not null,
`content` text not null,
primary key (`aid`),
key `cid` (`cid`)
) engine=myisam
insert into `test`.`article` (`aid`, `cid`, `content`) values ('', '7', '（jb51.net）教程');
执行explain：
explain select name, content from category, article where category.id = article.cid
得到结果：
explain列的解释：
id:选定的执行计划中查询的序列号。表示查询中执行select子句或操作表的顺序，id值越大优先级越高，越先被执行。id相同，执行顺序由上至下。
select_type：查询类型 说明
1、simple：简单的select查询，不使用union及子查询
2、primary：最外层的select查询
3、union：union中的第二个或随后的select查询，不依赖于外部查询的结果集
4、dependent union：union中的第二个或随后的select查询，依赖于外部查询的结果集
5、union result： union查询的结果集subquery子查询中的第一个select查询，不依赖于外部查询的结果集
6、dependent subquery:子查询中的第一个select查询，依赖于外部查询的结果集derived用于from子句里有子查询的情况。
mysql会递归执行这些子查询，把结果放在临时表里。
7、uncacheable subquery:结果集不能被缓存的子查询，必须重新为外层查询的每一行进行评估
8、uncacheable union:union中的第二个或随后的select查询，属于不可缓存的子查询
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和all
all: full table scan ;mysql将遍历全表以找到匹配的行；
index ： index scan; index 和 all的区别在于index类型只遍历索引；
range：索引范围扫描，对索引的扫描开始于某一点，返回匹配值的行，常见与between ，< ,>等查询；
ref：非唯一性索引扫描，返回匹配某个单独值的所有行，常见于使用非唯一索引即唯一索引的非唯一前缀进行查找；
eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常用于主键或者唯一索引扫描；
const，system：当mysql对某查询某部分进行优化，并转为一个常量时，使用这些访问类型。如果将主键置于where列表中，mysql就能将该查询转化为一个常量。
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从where语句中选择一个合适的语句
key： 实际使用的索引。如果为null，则没有使用索引。很少的情况下，mysql会选择优化不足的索引。这种情况下，可以在select语句中使用use index（indexname）来强制使用一个索引或者用ignore index（indexname）来强制mysql忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：mysql认为必须检查的用来返回请求数据的行数
extra：关于mysql如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是using temporary和using filesort，意思mysql根本不能使用索引，结果是检索会很慢。
因为真正的优化会考虑到大数据，我会在后面写更详细的优化教程，今天累了！分享一个详细的mysql explain语法及使用教程（mysql_explain_语法详细解析.pdf）！