嵌套查詢與連接查詢的性能：連接查詢一般較快；子查詢很難被優化。(當然和DB優化有關，也可能子查詢比連接查詢快)其實不能一概而論的~~

不過，問了下DBA同學，他建議是能用join的，盡量不要用嵌套查詢。以下內容，部分是來自網上的一些觀點，自己稍加整理的。子查詢是實現關聯式計算的一種實例，連接實現了關聯式代數。關于關聯式計算(relational calculus)和關聯式代數(relational algebra)，貌似比較數學或者理論性的東西理論，我也還沒深入弄明白。很多人也說到，這個性能的比較，不能一概而論的，需要具體的每個Case具體分析。也有人說(并有在某種DBMS上用一個例子證明)，子查詢可以也可能被優化為與join一樣的執行計劃，性能可以一樣的。說一下概念吧：在一個SELECT語句的WHERE子句或HAVING子句中嵌套另一個SELECT語句的查詢稱為嵌套查詢，又稱子查詢。一個select...From...Where查詢語句塊可以嵌套在另一個select...From...Where查詢塊的Where子句中，稱為嵌套查詢。外層查詢稱為父查詢，主查詢。內層查詢稱為子查詢，從查詢。子查詢可以嵌套多層，子查詢查詢到的結果又成為父查詢的條件。子查詢中不能有order

by分組語句。先處理子查詢，再處理父查詢。 子查詢除非能確保內層select只返回一個行的值,否則應在外層where子句中用一個in限定符,即要返回多個值，要用in或者not in哦，所以當在編譯過程中出現“子查詢只返回一個值”的錯誤時，就要考慮是不是要用in和not in.可以自己用寫個PL/SQL寫一段來看執行時間的差異，不過由于dbms的優化，我執行了幾次，結果都不每次效率一致，因為查詢后可能在dbms端由緩存、優化之類的：declare

time1 timestamp(3);

time2 timestamp(3);

cou number;

begin

select current_timestamp into time1 from dual;

select count(p.id) into cou from product p where p.company_id in (select c.id from company c);

--select count(p.id) into cou from product p inner join company c on p.company_id=c.id;

select current_timestamp into time2 from dual;

dbms_output.put_line(time1);

dbms_output.put_line(time2);

dbms_output.put_line(time2-time1);

dbms_output.put_line(cou);

end;關于連接查詢，以前總結過一下：http://www.51testing.com/index.php?uid-225738-action-viewspace-itemid-210222下面是我所查到的網頁中的一些摘錄：Joining should always be faster - theoretically and realistically. Subqueries- particularly correlated - can be very difficult to optimise.

If you thinkabout it you will see why - technically, the subquery could be executed oncefor each row of the outer query.Subqueries such as that described are one instance of the way thatSQLimplements

relational calculus (you will see that it is basically an "Exists" type ofoperation). Joins are an implementation of relational algebra. The optimisation of relational algebraic operations is *very* well understood,

while the calculus is much more difficult to optimise...Realistically, most good DBMSs will optimise a query such as yours to use a join instead, thus converting the implementation from calculus

to algebra.In general, subqueries - particularly correlated - should be avoided unless absolutely necessary. It makes the query harder to read/maintain,

pushes more work onto theserver,

and is generally just a far less appropriate style. of SQL.subquery is faster when we have to retrieve data from large number of tables.Because it becomes tedious to join more tables. join is faster

to retrieve data from database when we have less number of tablesIn general there is no reason to assume that a subquery will be faster or slower than a join.? Specific cases can point one way or the

other, but there are too many variables for a general answer.? There are cases where a subquery should be faster - an EXISTStestagainst

a JOIN, where the EXISTS stops at the first match but the JOIN has to deal with every match.Note that in many cases the optimizer rewrites queries with correlated subqueries as outer joins, so in many cases the performance is the

same.更多相關討論：http://forums.devx.com/showthread.php?t=24593http://www.eggheadcafe.com/software/aspnet/32705705/join-vs-subquery.aspxhttp://blog.csdn.net/zxs820329/archive/2008/02/14/2094927.aspx

總結

以上是生活随笔為你收集整理的db2嵌套查询效率_嵌套查询与连接查询的性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。