|
|
楼主用的应该是MYISAM存储引擎，
meishiid我猜想是int，
userid我猜想是int
explain的ROWS是估算值，跟统计信息有关系，他不是一个准确值。
楼主的查询说了这个表有7W，楼主取值范围应该涉及好几万。
select MeiShiID,Title from fc_meishi_old where MeiShiID>12586 order by MeiShiID ASC LIMIT 0,1;
这个查询不会读取表的所有数据，根据下面的索引看
PRIMARY KEY (`MeiShiID`,`UserID`),
KEY `Title` (`Title`,`MeiShiID`) USING BTREE,
SQL根据meishiid查询MeiShiID,Title，meishiid是主键前缀，mysql会选择搜索meishiid的索引，
但是从meishiid不能取得title，那么该值不是从索引中直接获取的，explain后面应该是using where，不出现using index。
MeiShiID>12586 表示一个范围查询，会查满足条件的所有值，所以后面ROWS不会是1.
PRIMARY KEY (`MeiShiID`,`UserID`), meishiid是前缀索引，而且是主键，
楼主order by MeiShiID ASC， 楼主的meishiid是自增长序列，索引是有序的，这里得到的就一个优化好的结果，不会using filesort。
limit 0,1读取第一行反馈给用户，这里的limit 0,1是从 SQL的结果集中读取第一行给用户。
limit不是一个优化MYSQL查询的可靠手段，如果SQL结果集很大，使用了limit 0,1仍然会很慢。直接让SQL返回合理的行数才是王道。
Rows sent : 1 avg, 1 to 1 max (0.35%) 这个虽然是统计信息，但可以知道是limit 0,1使用的结果。
Rows examined : 13.33k avg, 131 to 30.99k max (7.98%) 这个和explain 的ROWS有关，但是他们一个是统计信息，一个是explain即时查询，没有可比性。要关注表的当前状况。
说了一大堆废话，我就是想说，楼主执行explain的时候，表里面满足MeiShiID>12586条件的值还有几个。
还有MeiShiID既然是自增的，那么MeiShiID>values，values越大，Rows examined应该越小才对啊。 |
|
楼主: wanan_YLF
IP卡
狗仔卡
楼主
显身卡
发表于 2011-3-25 09:29
