在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子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

    在SQL语句中，LIKE关键字支持通配符匹配，但这种匹配特别耗费时间。

    例如：SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引，在这种情况下也还是采用顺序扫描的方式，Order表中有1000条记录，就需要比较1000次。

    如果把语句改为SELECT * FROM Order WHERE CreateUser>= ’M’ AND CreateUser<’N’，在执行查询时就会利用索引来查询，显然会大大提高速度。

    我们在编写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 联合大于小于操作来替换。

    虽然Notin和Notexits可以实现相同的功能，但是两者本身的实现方式不同： NotIn：是自内向外操作，即先得到子查询结果，然后执行外层查询。Notin子句的执行顺序是：首先取外部一个查询结果与内部子集比较，不管是否存在，它都要遍历整个子集，往往无法利用到索引，因而是由内向外过程。所以，当内部查询子集很大时，就会具有较高的查询代价。  NotExists：恰恰相反，是外向内操作。即先执行外部查询结果，然后再执行内部操作，是集合操作。Notexists子句的执行顺序是：首先取外部一个查询结果与内部子集比较，若存在即刻返回，而不需要遍历整个子集，如果存在索引，就会使用索引，因而是个自外而内的过程。所以，当内部子集很大时，相对来说，性能要优于Notin。  因而，总的来说，Notexits在整体性能上要由于Notin。原则： 当子查询结果集较大时，Notexists较Notin具有较高的性能提升；  当子查询结果集较小时（个数或者百数以内），两者相差不多，一般来说，此时Notin会优于Notexists。就好像表数据小时，全表扫描总是要由于索引扫描；当子查询具有一定的复杂度时（即sql关联关系较多，如子查询句中包含多个表查询），由于内部查询的复杂度，会导致Notexists查询具有较大的复杂度，降低性能。此时可以考虑采用Notin。  IN与Exists两者相差不多，这里不做比较，思路相同。

 

     使用distinct是为了保证在结果集中不出现重复值，但是distinct会产生一张工作表，并进行排序来删除重复记录，这会大大增加查询和I/O的操作次数。因此应当避免使用distinct关键字。

 

      表连接有两个要点：

      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 字句后的条件）建立索引，会得到很好的性能提升。

      表连接时连接字段只有一个会更好。