SQL优化

   SQL的优化无外乎是为了提高查询的效率,更快的获取大数据资源,避免在业务环节耽误时间,当然也是为了更好的用户体验.

最近针对SQL优化做了一定了解和实践,故记录下,以后也好复习,加强记忆.

1.SQL优化的前奏

        在SQL的可以可视化工具中,使用Explain语句判断自己的SQL语句写的是不是有待优化,尤其是索引,有效的索引可以提高我们的查询效率,但是也不能为了加快查询速度加过多的索引.

 1.1Explain语句的优点

    执行Explain语句会得到以下标准

select_type:select查询类型,

    SIMPLE   ：表示简单查询，其中不包括连接查询和子查询;

    PRIMARY：表示主查询，或者是最外层的查询语句;

    UNION    ：表示连接查询的第二个或后面的查询语句;

table:代表表

type:

    表示表的连接类型。该参数有几个常用的取值：

    const   ：表示表中有多条记录，但只从表中查询一条记录;

    eq_ref ：表示多表连接时，后面的表使用了UNIQUE或者PRIMARY KEY;

    ref       ：表示多表查询时，后面的表使用了普通索引;

    unique_ subquery：表示子查询中使用了UNIQUE或者PRIMARY KEY;

    index_ subquery：表示子查询中使用了普通索引; range  ：表示查询语句中给出了查询范围;

    index   ：表示对表中的索引进行了完整的扫描;

    all        ：表示此次查询进行了全表扫描; ----------- 该条SQL需要优化；

一般而言,在工作中遇到需要优化的SQL最多就是ALL,ALL代表着是查询全部的原数据,如果数据量比较少还体现不出什么效果,但是一旦数据量增长到万,百万,千万,name这个就体现的很明显了,所以无论大小,优化为好.

1.2 Explain得出的结论

1.使用适当的索引比不使用索引的速度要快很多

2.使用模糊查询是,如果没必要,不要讲"%"放在第一位,这样会导致全表扫描,查询速度会很慢.

2.常见的SQL优化

1.尽可能避免使用select *,将字段描述出来

2.字段值不要使用null,这样在查询条件中就不会使用 字段 is null,使用特定的数字代表即可

3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

4.不要在查询条件中使用or,可以使用union all来连接查询

5.查询条件中in 和 not in要慎用,可以使用Exist来代替in

6.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，

7.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。可以采取分页来试下

8.建立索引时,应优先考虑在where语句和order by 的字段上加索引