怎么样去优化我们的SQL语句

1、改写in
在SQL语言中,一个查询块可以作为另一个查询块中谓词的一个操作数。因此,SQL查询可以层层嵌套。例如在一个大型分布式数据库系统中,有订单表Order、订单信息表OrderDetail,如果需要两表关联查询:  
SELECT CreateUser FROM Order  WHERE OrderNo IN   ( SELECT OrderNo  FROM OrderDetail  WHERE Price=0.5) 
 
可替代方案:  
SELECT CreateUser FROM Order,OrderDetail WHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5   
一个列的标签同时在主查询和where子句中的查询中出现,那么很可能当主查询中的列值改变之后,子查询必须重新查询一次。查询嵌套层次越多,效率越低,因此应当尽量避免子查询。如果子查询不可避免,那么要在子查询中过滤掉尽可能多的行。
 
2 、改写LIKE 
    在SQL语句中,LIKE关键字支持通配符匹配,但这种匹配特别耗费时间
    例如:SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引,在这种情况下也还是采用顺序扫描的方式,Order表中有1000条记录,就需要比较1000次。
    如果把语句改为SELECT * FROM Order WHERE CreateUser>= ’M’ AND CreateUser<’N’,在执行查询时就会利用索引来查询,显然会大大提高速度。
 
3、改写OR或<>
    我们在编写sql时,通常都会按照程序逻辑去写,此时,当我们遇到如下场景: 我要查询企业员工表(employee)中的员工状态为实习(type=’01’)或者兼职的所有员工(type=’08’),假设状态共有10种 此时,我们立马会写如下Sql:  
Select * from employee A  whereA.type=’01’ or A.type=’08’
    我们假设,在type列上存在索引。而此Sql含有or运算,对于优化器来说,因为无法运用到一个范围,所以无法利用索引扫描。而通常此种情况需要遍历所有记录或者所有索引。这样会明显提高查询cost。我们希望是通过索引的方式,毕竟该表是个大表,如果出现大表扫描,多系统性能有很大的影响。那么可以采取用UNION改写OR子句,如下:  
Select * from employee A  whereA.type=’01’  union  Select * from employee A  whereA.type=’02
    改写成上述sql,优化器会分别执行两个查询子集,然后union合并。这样就可以利用到索引(type=‘01’)。当然Union包含去除重复元素的功能,即相当于distinct,这样就会有排序存在,如果业务场景允许,可以考虑使用union all,它和union不同的是,它无需排序去重,只需要两个子集合并即刻。效率要高于union。原则是:  当存在大表链接且连接条件较多,并且连接条件包含Or子句时,建议使用Union/Union all来替换。  对于不等与来说也是类似,不等于在逻辑上其实是类似于 Not 的概念。
 
如,对如下sql: 
Sql_stmt_2:  Select * from employee where type !=’01’ 所以我们可以有如下改写方式: 
1) 将<>改写为Not in操作,即  Select * from employee where type not in (‘01’) 
2) 将<>改写为大于和小于的结合  Select * from employee where type >’01’ union   Select * from employee where type <’01’(当然如果你知道一个大于已经足够,那么完全可以省略掉小于的操作,这就是分析sql的业务场景)  
显然,对于1)的改法,它适用与Not in 子集中有多个值的情况;对于2)改法,要要由于1),因为它可以利用到Type列上的索引。 原则是:  当存在大表链接且连接条件较多,并且连接条件包含不等于(<>||!=)子句时,建议使用Union/Union all 联合大于小于操作来替换。
 
 
4 合理使用Notin和NotExists
    虽然Notin和Notexits可以实现相同的功能,但是两者本身的实现方式不同: NotIn:是自内向外操作,即先得到子查询结果,然后执行外层查询。Notin子句的执行顺序是:首先取外部一个查询结果与内部子集比较,不管是否存在,它都要遍历整个子集,往往无法利用到索引,因而是由内向外过程。所以,当内部查询子集很大时,就会具有较高的查询代价。  NotExists:恰恰相反,是外向内操作。即先执行外部查询结果,然后再执行内部操作,是集合操作。Notexists子句的执行顺序是:首先取外部一个查询结果与内部子集比较,若存在即刻返回,而不需要遍历整个子集,如果存在索引,就会使用索引,因而是个自外而内的过程。所以,当内部子集很大时,相对来说,性能要优于Notin。  因而,总的来说,Notexits在整体性能上要由于Notin原则: 当子查询结果集较大时,Notexists较Notin具有较高的性能提升;  当子查询结果集较小时(个数或者百数以内),两者相差不多,一般来说,此时Notin会优于Notexists。就好像表数据小时,全表扫描总是要由于索引扫描;当子查询具有一定的复杂度时(即sql关联关系较多,如子查询句中包含多个表查询),由于内部查询的复杂度,会导致Notexists查询具有较大的复杂度,降低性能。此时可以考虑采用Notin。  IN与Exists两者相差不多,这里不做比较,思路相同。
 
5 避免使用distinct  
     使用distinct是为了保证在结果集中不出现重复值,但是distinct会产生一张工作表,并进行排序来删除重复记录,这会大大增加查询和I/O的操作次数。因此应当避免使用distinct关键字。
 
6 表连接
      表连接有两个要点:
      1)表连接顺序 2)连接条件 
      Sql_stmt_1:  Select  *  from  A  left  join  B  on  A.id=B.id join C on B.id = C.C_id  where A.con=’ ’ and B.con=’ ’  
      一般情况下,DB2会根据各表的JOIN顺序自顶向下处理,即从Sql来看,就是自左向右解析,先A、B做连接操作,之后会产生结果集,将会写入内存,如果内存不够,会写入临时表空间,之后会用结果集和C做连接操作。如果sql中只有两表连接,那么其前后顺序没什么关系,优化器会自己去评估。而如果sql中存在超过2个表连接时,那么表连接就会有顺序之分。
      那么,原则是:  如果sql中存在表A、B、C三表连接,则首先应保证最先连接的两表具有较小的子集。  在进行表连接时,需要提供连接字段(即On语法后的等价谓词,on A.id=B.id)。此时,我们需要保证,连接字段存在索引。这样当结果集小时,会走NestJoin(速度快,因为会利用到索引),当结果集大时,会走Hash join。此外,在对A、B表进行连接时,优化器需要判断采用何种连接类型,这时会先执行where 字句后的条件。也就是说,如果where字句能过滤很多的条件,那么表连接的结果集就会很小,cost自然会降低,所以适当为where字句的查询字段建立索引,能够得到更好的性能。原则:  在进行表连接时,为连接字段和查询过滤字段(where 字句后的条件)建立索引,会得到很好的性能提升。
      表连接时连接字段只有一个会更好。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。