请问,像下面这些条件需要建几个复合索引才合适呢? 
然后在sql语句及复合索引中字段的前后排序有没有关系?//(在一个文章系统里较常用的几个查询)WHERE id>80547 AND find_in_set('27',sortid) AND islock=1 ORDER BY id DESC 
WHERE id>80547 AND find_in_set('22',sortid) AND islock=1 AND attid='1' ORDER BY id DESC
WHERE id>80547 AND find_in_set('24',sortid) AND islock=1 AND topid='2' ORDER BY id DESC 
WHERE find_in_set('22',sortid) AND islock=1 AND attid='1' WHERE id>80547 AND islock=1 AND author='2' ORDER BY id DESC 
WHERE islock=1 AND author='1' ORDER BY id DESC 
WHERE id>80547 AND islock=1 AND isbest='2' ORDER BY id DESC 
其中id为自增ID也是主键,id>80547这个条件是为了省略过去查更多的数据。 我有尝试建立了两个,但都不见成效,不知还有什么地方可以改善的?请指点,谢谢。
CREATE INDEX idx_sortid_islock_attid_id ON article (sortid,islock,attid,id);
CREATE INDEX idx_author_islock ON article (author,islock);
还有一个问题,在InnoDB下count()相当的吃力,很慢,不知有没有其它方法?SELECT COUNT(id) FROM article WHERE find_in_set('3',sortid) AND islock=1 AND attid='1';上面这个统计竟然花了14.230s,14900条记录

解决方案 »

  1.   

    补充一下,现在这个表里约有12W左右的行数,当前只建一个单独索引(sortid)。
    现在的查询速度都比较慢,字段类型分别为:
    sortid=varchar(32),
    islock=tinyint(1),
    attid=tinyint(2),
    author=smallint(4),
    topid=tinyint(1)
      

  2.   

    这个你之前不是有问过了的吗?好象之前都有很详细的回答过你的吧?这个不是在现场环境上测试跟踪的话, 也只是从你的查询语句在大的面上帮你说下罢啦,因为这个优化的东西涉及到的因素很多,例如,你表记录的值分布情况、表统计信息情况、表记录的更新删除是否较多、每行记录的大小等等。CREATE INDEX idx_sortid_islock_attid_id ON article (sortid,islock,attid,id); ---根据你的查询,觉得你这个索引没用,因为前缀用得不对还有一个问题,在InnoDB下count()相当的吃力,很慢,不知有没有其它方法? -----根据你上面查询语句和索引情况,估计表扫描的范围很大,所以当然慢啦,不信你可以直接 select count(id) from article 看看,这个应该挺快的。
      

  3.   


    谢谢vinsonshen.有问过,但仍是不得到满意的效果所以继续折腾…
    这个索引没用,因为前缀用得不对...
    ---那我要如何改善呢?select count(id) from article
    ---已试过,不加条件依然是很慢,查了下手册说InnoDB下加不加条件都是要全表扫描…
      

  4.   


    建议索引 (islock,author,id)