这条mysql话语explain看起来已经很优化的了，但是执行起来要十几秒

这条mysql语句explain看起来已经很优化的了，但是执行起来要十几秒

表记录：一百多万吧。

SQL语句：

SQL code

  
EXPLAIN
SELECT title,add_time 
FROM `picture`   WHERE ( picture.cid = 11 ) 
AND ( `is_show` >= 0 ) AND ( `show_time` >= 1333382399 ) 
ORDER BY `id` DESC LIMIT 0,10

以下是EXPLAIN的结果：

SQL code

  
"id","select_type","table","type","possible_keys","key","key_len","ref","rows","Extra"
"1","SIMPLE","picture","index","cid","PRIMARY","4",\N,"657","Using where"

cid的索引是多列索引：

cid,show_time,id

三个字段的组合索引。

是什么原因导致查询结果这么慢呢？？？EXPLAIn看得出是哪里问题吗？感觉已经是够优化的了啊。

create index xxx on picture(cid,show_time,is_show)




is_show有几种值？去掉ORDER BY速度有无变化

( picture.cid = 11 ) 

AND ( `is_show` >= 0 ) AND ( `show_time` >= 1333382399 ) 

在这三列上建立联合索引




cid,show_time,is_show三字段没有索引或有索引没有用到。




你的explain看的太累了，建议你下次截屏。

explain的结果是有问题的，Possible_key是cid，但是实际使用的key是”PRIMARY”,实际使用的Key长度是4。

也就是说，MySQL最后选择了使用Primary主键来全表查询，所以需要这么长的时间。

MySQL认为排序的代价太大了，它更偏向于使用Primary来走索引，而不是走cid的索引，得到数据，然后再排序。这里也是一直被很多人诟病的MySQL的缺点：查询优化器比较弱。

建议：

order by id修改成order by cid，id，cid由于是固定的，所以不会影响结果，但是MySQL的优化器应该会走到cid的多列索引。

不建议使用force index，这个东西的副作用优点大。