mysql sort 性能优化

通过一些常用的查询语句分析方法，对查询语句进行优化。
1，explain，这个绝对是神器。
在一个select语句前添加explain，会得到以下内容
id  select_type table  type  possible_keys  key   key_len    ref   rows    Extra
1 SIMPLE    a   ALL null        null   null null 4578 Using filesort
这里比较重要的要关注的字段是type，rows，Extra
下面分别说一下，
type字段All，index，range，ref，eq_ref,const和system,null
由左至右，由最差到最好
也就是说，如果一个select比较慢，explain时type里面的值为All，那么这个就要注意了，可以优化了。
rows表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数
这个主要是作为一个优化的参考，不一定说rows多的就比rows少的慢，比如进行一个语句直接查询rows有十万，一个语句查询后要进行排序，
虽然rows只有一万，但是可能更慢。
Extra这个是重点
Using index
该值表示相应的select操作中使用了覆盖索引（Covering Index）
MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件
包含所有满足查询需要的数据的索引称为 覆盖索引（Covering Index）
注意：
如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select *，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降
Using where
表示MySQL服务器在存储引擎受到记录后进行“后过滤”（Post-filter）,
如果查询未能使用索引，Using where的作用只是提醒我们MySQL将用where子句来过滤结果集
Using temporary
表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询
Using filesort （这个如果出现，要重点关注）
MySQL中无法利用索引完成的排序操作称为“文件排序”


项目中出现的问题是一个更新语句有时会出现很慢的情况，分析得出Using filesort。order by后面的主键索引没有被使用，原因是where中的条件使用了索引。后面的
索引没有发挥作用。
这里采用了一个比较大胆的修改方式
force index(PRIMARY)，在语句后面添加这个，强制使用主键作为索引查询。
发现效果很明显。


-----------分割线-----------------
按照上面的方法修改后，之前特别慢的产品没有问题，但是其他所有的产品速度都变得很慢，
囧
后来继续分析后，决定使用联合索引，对where条件中的两个查询字段添加一个联合索引
问题解决。




思考，遇到这类型的问题，第一步，explain不解释，然后分析extra，看看是否有什么问题，一般都有问题，不然也不会慢。对于出现using filesort的考虑对
查询条件创建一个联合索引