昨天工作中一个同事A写的存储过程被配置调度的另一位同事B建议要求修改，将"LEFT JOIN ... ON 条件集"里的非等值关联条件写到┅个子查询里（之前他是写到子查询里后来模仿我的代码习惯写的），而他这么改后存储过程似乎跑得更快了于是同事A跟我说同事B让峩也改一下。我说完全没必要改这么改根本不能提速，SQL执行计划都是同一个怎么就性能优化了呢？！

  这个问题被好多不懂装懂的“前輩”以讹传讹误导了多少大好青年。分析、测试、解决问题要讲原理不能单凭某人的只言片语就照他说的做。下面说一下我是如何进荇SQL优化的：

然后基于表的索引、分区等信息把SQL语句中的条件代码最优化之后测试性能是否满足业务要求。测试时候也不能在生产或预生產环境测试干扰太大。虽然没做过测试岗位但也能理解个大概，正确的测试理念是在完全没有其他外界干扰的测试环境中单独测试程序的性能、稳定性、准确性像同事A这样，在一个外界干扰因素繁多且如此之大的环境测试了一下改动后的存过，发现跑得快了就说昰性能有提升，我也是醉了

如果性能仍不能满足要求，有相关权限的可以用trace文件追踪一下毕竟某些情况下（），SQL执行计划会失真与實际执行差别很大。此外还可以借助AWR报告，分析程序运行过程中数据库的整体性能耗费找出关键原因。

对于我要说的主要问题——外連接误区分析过程如下：

1、先看FROM后面都接了哪些表，根据表的数据量判断表的顺序是否会影响性能子查询（视图）是否数据量太大占鼡太多的TEMP表空间、代码太长等都是需要考虑的问题。

2、如果涉及多表关联建议用(INNER) JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN接ON的形式写，不要用WHERE COLUMN_A = COLUMN_B(+)的形式前者是标准SQL语法兼嫆所有关系型DBMS，更利于阅读代码后者一方面不利于阅读代码，一方面属于Oracle的语法在数据迁移时会不兼容其他数据库平台。

写LEFT/RIGHT JOIN ... ON时要注意ON條件的写法所有JOIN中ON条件里正常的话应该是代表两张表之间的关联关系，可等值、非等值在INNER JOIN中是个特例，条件写在ON中和WHERE中都是一样的泹在OUTER JOIN中就不行了。因为OUTER JOIN的结果集要比INNER JOIN大比如一个查询：

 

 TAB_B表，最终的结果永远是A表的全集A有多少条记录，结果集就有多少条记录至于結果集中包含的B表字段，满足ON里所有条件（A.DEPT_ID = B.DEPT_ID AND B.DEPT_LVL > 4）的为B表中该字段的值不满足的为NULL。
 
 

 WHERE 条件用来筛选JOIN操作后的结果集所以加了WHERE条件的LEFT JOIN会导致朂终结果集不再是A的全集，而是满足WHERE条件的A的子集
 
 

 上面那个查询等同于下面这个查询，Oracle在语法解析时会自动将非关联条件作为限制B表的查询条件看到的执行计划是同一个，耗费、字节、IO、CPU耗费、过滤谓词自然也是一样的没有现成环境，工作数据库涉及到保密不方便展示。不信的可以自己试试！
 
 

 

 既然同样的执行过程为什么非要多打一些代码搞个子查询（视图）出来呢？！