sql优化

type 
这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
说明：不同连接类型的解释（按照效率高低的顺序排序）

-------基本原则
1.永远用小结果集驱动大结果集；
From子句中sql解析顺序为从右向左，
执行时会以最左边的表为基础表循环与右边表数据做笛卡尔积，
所以以小结果集驱动能减少循环次数，从而减少对被驱动结果集的访问，
从而减少被驱动表的锁定
3.只取出子集需要的列
4.仅仅使用最有效的过滤条件；
5.尽可能避免复杂的Join和子查询；

0.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，解析的过程中, 会将‘*’依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间，不要返回用不到的任何字段。

1.查询大数据量,且插入不频繁的数据时用 索引

在经常需要进行检索的字段上创建索引，比如要按照姓名进行检索，那么就应该在姓名字段上创建索引，
建索引给检索带来的性能提升往往是巨大的，因此在发现检索速度过慢的时候应该首先想到的就是创建索引。
索引的好处： --不会出现在where子句中的字段不要创建索引；
（1）.提高数据检索效率，降低数据库的IO成本。
（2）.降低数据排序成本：要求排序字段和索引键字段一致。
（3）.降低数据分组成本：因为分组之前会先排序，同意如果分组字段与索引字段一致，会降低分组消耗的成本。
索引的弊端：
（1）.索引是独立于基础数据的数据库对象，因此它会占用存储空间。
（2）.数据新增、更新会导致索引的同步更新，所以会增加数据新增、更新所消耗的成本。
判断是否需要创建索引：
（1）.较为频繁的作为查询条件的字段需要创建索引；
（2）. 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件；
（3）.更新非常频繁的字段不适合创建索引；
（4）.不会出现在where子句中的字段不要创建索引；

2.调整where的连接顺序
解析where时是自下而上的(先执行where),根据原理表连接最好写在其他where条件之前
可以过滤掉最大数量记录。

3.尽量将多条SQL语句压缩到一句SQL中
每次执行SQL的时候都要建立网络连接、进行权限校验、进行SQL语句的查询优化、发送执行结果，这个过程
是非常耗时的，因此应该尽量避免过多的执行SQL语句，能够压缩到一句SQL执行的语句就不要用多条来执行

4.用where字句替换HAVING字句
having只会在检索出所有记录之后才对结果集进行过滤，而where则是在聚合前
刷选记录，如果能通过where字句限制记录的数目，那就能减少这方面的开销

5.使用表的别名
连接多个表时，请使用表的别名并把别名前缀于每个列名上。
这样就可以减少解析的时间并减少哪些友列名歧义引起的语法错误。

6：在in和exists中通常情况下使用EXISTS，因为in不走索引。
 IS NULL 或IS NOT NULL操作（判断字段是否为空）
推荐方案：用其它相同功能的操作运算代替，如：a is not null 改为 a>0 或a>’’等。
不允许字段为空，而用一个缺省值代替空值，如申请中状态字段不允许为空，缺省为申请。

7.避免在索引上使用计算,不要在 where 子句中的“=”左边进行函数、算术运算
在where语句中,如果索引列是计算或者函数的一部分,将不会使用索引而是用全表查询
 效率低：select * from person where salary*12>25000(salary是索引列)
 效率高：select * from person where salary>25000/12(salary是索引列)

8.避免 where 子句中使用!=或<> or in 和 not in
应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。    
应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫
in 和 not in 也要慎用，否则会导致全表扫描
下面的查询也将导致全表扫描：    
select id from t where name like '%abc%'

9.on、where、having这三个都可以加条件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合 条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该比having快点的，因为它过滤数据后才进 行sum，在两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。