本文主要向大家介紹了MySQL數據庫之嵌套查詢與連接查詢的性能詳解 ，通過具體的內容向大家展現，希望對大家學習MySQL數據庫有所幫助。

嵌套查詢與連接查詢的性能：連接查詢一般較快；子查詢很難被優化。(當然和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;

關于連接查詢，以前總結過一下：https://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?think

about?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?that?SQL?implements?relational?calculus?(you?will?see?that?it?is?basically?an?"Exists"?type?of

operation).?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?the?server,?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?tables

In?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?EXISTS?test?against?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.

本文由職坐標整理并發布，希望對同學們學習MySQL有所幫助，更多內容請關注職坐標數據庫MySQL數據庫頻道！

總結

以上是生活随笔為你收集整理的mysql 嵌套查询性能_MySQL数据库之嵌套查询与连接查询的性能详解的全部內容，希望文章能夠幫你解決所遇到的問題。

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