MySQL的Explain命令用于查看执行效果。虽然这个命令只能搭配select类型语句使用，如果你想查看update，delete类型语句中的索引效果，也不是太难的事情，只要保持条件不变，把类型转换成select就行了。
explain的语法如下：
explain[extended]select...from...where...
如果使用了extended，那么在执行完explain语句后，可以使用showwarnings语句查询相应的优化信息。
mk-visual-explain工具扩展了explain，它提供了一种更直观的树形表现形式，使用方法很简单：
mk-visual-explain
mk-visual-explain-c
mysql-e"explainselect*frommysql.user"|mk-visual-explain
也可以在MySQL命令行里通过设置pager的方式来执行：
mysql>pagermk-visual-explain
mysql>explain[extended]select...from...where...
进入正题，为了让例子更具体化，我们先来建一个表，插入一点测试数据：
CREATETABLEIFNOTEXISTS`article`(
`id`int(10)unsignedNOTNULLAUTO_INCREMENT,
`author_id`int(10)unsignedNOTNULL,
`category_id`int(10)unsignedNOTNULL,
`views`int(10)unsignedNOTNULL,
`comments`int(10)unsignedNOTNULL,
`title`varbinary(255)NOTNULL,
`content`textNOTNULL,
PRIMARYKEY(`id`)
);
INSERTINTO`article`
(`author_id`,`category_id`,`views`,`comments`,`title`,`content`)VALUES
(1,1,1,1,'1','1'),
(2,2,2,2,'2','2');
CREATETABLEIFNOTEXISTS`article`(
`id`int(10)unsignedNOTNULLAUTO_INCREMENT,
`author_id`int(10)unsignedNOTNULL,
`category_id`int(10)unsignedNOTNULL,
`views`int(10)unsignedNOTNULL,
`comments`int(10)unsignedNOTNULL,
`title`varbinary(255)NOTNULL,
`content`textNOTNULL,
PRIMARYKEY(`id`)
);
INSERTINTO`article`
(`author_id`,`category_id`,`views`,`comments`,`title`,`content`)VALUES
(1,1,1,1,'1','1'),
(2,2,2,2,'2','2');
缺省只建了一个主键，没有建其他的索引。测试时，如果你时间充裕，应该尽可能插入多一点的测试数据，怎么说也应该保证几千条。如果数据量过少，可能会影响MySQL在索引选择上的判断。如此一来，一旦产品上线，数据量增加。索引往往不会按照你的预想工作。
下面让我们设置一个任务：查询category_id为1且comments大于1的情况下，views最多的article_id。
问题很简单，SQL也很简单：
SELECTauthor_id
FROM`article`
WHEREcategory_id=1ANDcomments>1
ORDERBYviewsDESC
LIMIT1
SELECTauthor_id
FROM`article`
WHEREcategory_id=1ANDcomments>1
ORDERBYviewsDESC
LIMIT1
下面让我们用explain命令查看索引效果：
EXPLAINSELECTauthor_id
FROM`article`
WHEREcategory_id=1
ANDcomments>1
ORDERBYviewsDESC
LIMIT1
EXPLAINSELECTauthor_id
FROM`article`
WHEREcategory_id=1
ANDcomments>1
ORDERBYviewsDESC
LIMIT1
这时explain部分结果如下：
type:ALL
key:NULL
Extra:Usingwhere;Usingfilesort
显示数据库进行了全表扫描，没有用到索引，并且在过程中文件排序。这样的结果肯定是糟糕的，下面让我们通过建立索引优化一下它：
ALTERTABLE`article`ADDINDEXx(`category_id`,`comments`,`views`);
ALTERTABLE`article`ADDINDEXx(`category_id`,`comments`,`views`);
这时explain部分结果如下：
type:range
key:x
Extra:Usingwhere;Usingfilesort
虽然不再是全表扫描了，但是仍然存在文件排序。一般来说，文件排序都是由于ORDERBY语句一起的，而我们已经把views字段放到了联合索引里面，为什么没有效果呢？这是因为按照B-Tree的工作原理，先排序category_id，如果遇到相同的category_id则再排序comments，如果遇到相同的comments则再排序views。当comments字段在联合索引里处于中间位置时，因为comments>1条件是一个范围值，所以导致views部分索引无效。从这个意义上来说，此时的category_id,comments,views联合索引的效果不会比category_id,comments联合索引的效果好。
文件排序是否有问题要视数据分布而定。一般来说应该尽可能避免出现它。可以这样设置索引：
ALTERTABLE`article`ADDINDEXy(`category_id`,`views`);
ALTERTABLE`article`ADDINDEXy(`category_id`,`views`);
这时explain部分结果如下：
type:range
key:x
Extra:Usingwhere;Usingfilesort
很奇怪，系统无视我们刚建立的y索引，还使用x索引。导致仍然存在文件排序。
如果你也出现了类似的情况，可以使用强制索引：
EXPLAINSELECTauthor_id
FROM`article`
FORCEINDEX(y)
WHEREcategory_id=1
ANDcomments>1
ORDERBYviewsDESC
LIMIT1
EXPLAINSELECTauthor_id
FROM`article`
FORCEINDEX(y)
WHEREcategory_id=1
ANDcomments>1
ORDERBYviewsDESC
LIMIT1
这时explain部分结果如下：
type:ref
key:y
Extra:Usingwhere
当然，也可以删除x索引，那样系统会自动使用y索引。
2014-07-13 15:53:29