sql优化的一些小策略

以下是我进行整合的一些策略，不管是面试还是实战中常常会遇到这个问题

1、首先索引是大家都知道的一个问题

（1）负向条件查询不能使用索引

select * from order where status!=0 and stauts!=1

not in/not exists都不是好习惯

可以优化为in查询：

select * from order where status in(2,3)

（2）前导模糊查询不能使用索引

select * from order where desc like '%XX'

而非前导模糊查询则可以：

select * from order where desc like 'XX%'

（3）数据区分度不大的字段不宜使用索引

select * from user where sex=1

原因：性别只有男，女，每次过滤掉的数据很少，不宜使用索引。

经验上，能过滤80%数据时就可以使用索引。对于订单状态，如果状态值很少，不宜使用索引，如果状态值很多，能够过滤大量数据，则应该建立索引。

（4）在属性上进行计算不能命中索引

select * from order where YEAR(date) < = '2017'

即使date上建立了索引，也会全表扫描，可优化为值计算：

select * from order where date < = CURDATE()

或者：

select * from order where date < = '2017-01-01'

（5）复合索引最左前缀，并不是值SQL语句的where顺序要和复合索引一致

用户中心建立了(login_name, passwd)的复合索引

select * from user where login_name=? and passwd=?

select * from user where passwd=? and login_name=?

都能够命中索引

select * from user where login_name=?

也能命中索引，满足复合索引最左前缀

select * from user where passwd=?

不能命中索引，不满足复合索引最左前缀

2、业务逻辑最好放在业务层面，不要在数据库这边。

3、频繁的commit事务，因为维护一个事务也是需要资源。

4、考虑使用“临时表”暂存中间结果

简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。

5、尽量少用视图

6、将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。 

这点好理解

7、尽量使用批处理

http://www.cnblogs.com/petitprince/archive/2010/11/23/1885994.html