如果强制FORCE INDEX(PRIMARY)  那么当limit X,Y的X很大的时候可能会慢

解决方案 »

  1.   

    where的用不用索引 跟 order by 用不用索引是没必然关系的
    你可以在A的id上建立索引再试试看
      

  2.   


    * 用于搜索记录的索引键和做 ORDER BY 的不是同一个:
    SELECT * FROM t1 WHERE key2=constant ORDER BY key1; 
    这种情况查询器只能选择一个索引
      

  3.   

    可以贴出explain select ... 以供分析讨论。
      

  4.   


    目前就是这种情况,如果用FORCE INDEX(PRIMARY) , where的索引就不能用,所以说,有什么好办法,where 和 order by的索引都能生效?主要是where的数目不确定(有的是象根据文字的列(有索引),有些是选择"是","否"这类非索引)
      

  5.   

    问题应该出在filesort上。
    应先打开大表,因此a后面应该是跟left join。b、c、d应尽量与a关联,where中如果没有b、c、d表字段的条件就最好。
    优化方式是将id作为复合索引的一部分。比如 select * from tab_a where field_a='xxx' order by field_b limit xx;
    增加key xxx (field_a,field_b asc)有助于优化该语句。