索引优化

1. LIKE：只有后边带%才会用索引，前边或者前后都带的索引不生效（LIKE ‘%275024%‘，此时不生效）
2. !=：无法使用索引
3. OR：需要给字段单独添加索引，否则不生效
4. 索引列上有函数运算或隐式转换，导致不走索引；                                                                                                                                                                       如SELECT * FROM T WHERE date_format(Y) = XXX ，这时会先遍历T表Y列转换时间格式，同理函数会先遍历运算，导致用不上索引； 可以为函数加函数索引。
5. IN 大部分情况下会导致索引无法命中，如果外表大内表小可以用IN；如果外表小而内表大，则改成用exists。
6. NOT IN 同上，可与not exists合理安排使用

引导列要选择过滤条件的列作为引导列，比如 where a.xxx=‘xxx‘ 或者 a.xxx> 或者 a.xxx<  
引导列的选择性越高越好，因为选择性越高，扫描的leaf block就越少，效率就越高  (正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好的满足排序和分组的需要。在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列。所以，索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的ORDER BY、GROUP BY和DISTINCT等子句的查询需求。对于如何选择索引顺序有一个经验法则：将选择性较高的列放到索引的最前列。)
尽量把join列放到组合索引最后面  

join要保证小表驱动大表原则，如果查询计划显示大表驱动小表，可通过添加索引等方式变更驱动顺序

1、单索引

　　where哪些字段，就order by哪些字段

2、复合索引

　　where 和 order by 按照复合索引顺序使用，不要跨列或无需使用。

3、Extra出现using temporary（用到了临时表），常见于group by

　　查询哪些列就用哪些列分组。