sql多表查詢效率

① sql連表查詢跟一個個表查詢那個快各有什麼優點和缺點

SQL連表查詢稱為聯合查詢，一個個表查詢是單查詢。兩者的區別和優缺點如下：

1、從開發效率來看：

聯合查詢是需要多個單查詢進行邏輯組合才能完成的查詢的工作，聯合查詢僅僅需要一個SQL就可以完成查詢工作，即把業務邏輯放到了SQL中，由資料庫來處理，相對來說開發效率會比較高些。

2、從查詢效率來看：

單查詢的可重用性較高，所以效率相較之聯合查詢會更高。

在資料庫進行讀寫時，資料庫會用鎖機制，限制其他連接對其操作。由於聯合查詢查詢速度比單個查詢要慢很多，這樣聯合查詢會增加鎖的競爭關系，所以用單查詢會更好。

3、從邏輯架構分層原則來看

關聯關系代表了業務規則/邏輯，如果大量使用關聯查詢，就是把大量的業務規則和邏輯放在資料庫來執行了，資料庫消耗cpu、內存、io等資源會大大增加。

4、從資源利用率方面看

大部分場景下，並不是所有關聯查詢的結果都被有效使用了。例如後台管理的列表界面會分頁顯示，關聯查詢的結果集，只有當前頁的數據被使用，但資料庫需要消耗額外資源得到全部結果集。

5、從架構的伸縮性方面看

大量的關聯查詢會導致集中式的資料庫架構很難向分布式架構轉換，伸縮性方面的優化難度高。關聯查詢方便快速，開發效率比較好。

不使用關聯查詢在架構層面有很多優點，但對系統分析和設計、開發能力要求高。一般在互聯網行業等用戶數較多的情況下最好重視這方面。

題主的兩個查詢由於數據量不多，效率上基本沒有差別，但在實際應用中要根據數據量、業務復雜度等去綜合評估。

② 多表關聯查詢效率就很低，有沒有隻改SQL的優化方案

確實會發生這樣的情況，我也有此經歷，發生這樣的狀況是在Oracle資料庫下，而查詢涉及的一個表的數據量很大，假設為A表，在開始的時候並未帶出A的欄位，所以查詢速度還可以；後來查詢帶上A表的一個欄位，執行很久沒有結果。從執行計劃中可以看到，增加欄位前後查詢的執行計劃發生變化了，沒有帶A的欄位時，A表有按索引查詢，而帶A表的欄位之後，A表則未按索引查詢，而是表掃描，這當然很耗時間了!
經過反復試驗都是如此，後來只好改變查詢將獲取A表的欄位放到子查詢中執行，才避免了速度變慢。
對應此種情況，我們一般要改變查詢語句，或者增加索引，以使查詢走索引，這樣才不會效率低下。

③ SQL中，多表連接查詢和不相關子查詢從查詢效率上來說，哪種查詢的效果更好為什麼

一般說不相關子查詢效率高些，但也要看你的SQL語句怎麼寫。
如果不相關子查詢的語句查詢的數據量較大，那效率上和多表連接查詢差不多，如：
select * from a where a.age>(select max(age) from b)
如果子查詢僅僅查詢符合邏輯存在判斷的語法，那效率遠遠高於連接查詢，如：
select * from a where exists(select 1 from b where rownum<=1)

④ 多表連接查詢和多次單表查詢哪個效率高為什麼

如果數據量小的表，這樣的設計意義不大，而且當然是單錶速度快。若在大數據量情況下，設計非常有意義。在多表連接中注意數據的條目和外健，避免出行大量冗餘數據導致性能下降。下面我以Oracle講講數據查詢的整個過程技術。

由於數據分布到數據塊，在大量數據設計中可以將數據存儲於多個數據塊，在高並發進程的隨機訪問的情況下，能有效減少塊沖突 同樣的數據需要更多的數據塊來存儲，由於數據塊的塊頭元信息大小固定，所以需要更多的空間來存儲塊頭元信息。行長度過大容易導致行連接，從而導致Oracle獲取數據塊的效率降低 ，在行長度固定的前提下，單塊能夠存儲更多的數據行，也就意味著Oracle一次I/O能讀取更多的數據行。適合連續順序讀或者存放大對象數據（如LOB數據） 由於大數據塊可以存放更多的索引葉節點信息，容易引起爭用，所以大數據塊不適合存放索引葉節點信息。

大量數據表的資料庫參數設置DB_FILE_MULTIBLOCK_READ_COUNT表示Oracle一次順序I/O讀操作最多能讀取的數據塊塊數。該參數的默認值隨操作系統的不同而不同。在全表掃描或者索引快速掃描比較多的系統中（如DSS系統），建議將該值設置得較大。但是DB_FILE_MULTIBLOCK_READ_COUNT參數受操作最大單次I/O大小的限制，大多數操作系統單次讀操作的大小不能超過1MB，這也就意味著在8KB數據塊大小的情況下，該參數最大值為128。值得一提的是，該參數的大小還會影響Oracle CBO對執行計劃的評估，如果設成較大值，Oracle的執行計劃傾向於全表掃描。當該參數設置為0或者保持默認時，CBO假設全表掃描時最多能連續讀取8個數據塊。從Oracle 11R2開始，DB_FILE_MULTIBLOCK_READ_COUNT的取值演算法如下：

db_file_multiblock_read_count = min(1048576/db_block_size , db_cache_size/

(sessions * db_block_size))

注意資料庫參數BLOCK_SIZE在設定之後，在資料庫生命周期內不可更改。

當執行SELECT語句時，如果在內存里找不到相應的數據，就會從磁碟讀取進而緩存至LRU末端（冷端），這個過程就叫物理讀。當相應數據已在內存，就會邏輯讀。我物理讀是磁碟讀，邏輯讀是內存讀；內存讀的速度遠比磁碟讀來得快。

下面將本人大數據分區設計截圖，為大家參考學習。

先貼倆圖鎮鎮場。

引言

對於內連接，使用單個查詢是有意義的，因為你只獲得匹配的行。

對於左連接，多個查詢要好得多。

數據說話

看看下面的基準測試:

5個連接的單個查詢

一行5個查詢

注意，我們在兩種情況下得到了 相同的結果 (6 x 50 x 7 x 12 x 90 = 2268000)

總結一下

對於冗餘數據，左連接使用更多的內存。

如果只執行兩個表的連接，那麼內存限制可能沒有那麼糟糕，但通常是三個或更多的表，因此值得進行不同的查詢。

寫在最後

用過Laravel嗎？還記得 Eloquent ORM模型嗎？

不知道有沒有注意到，debug所列印出來的多表聯合查詢，

都是拆分為「單個表查詢」，然後使用PHP處理的。

Happy coding :-)

是做表連接查詢還是做分解查詢要具體情況具體分析。

如果資料庫的結構合理，索引設計得當，表連接的效率要高於分解查詢。比如，在有外鍵的時候，資料庫可以為外鍵建表並建立索引從而提升多個表連接查詢的效率。另外，多表連接查詢不需要把數據傳輸到應用程序中，直接在資料庫端執行，這在很大程度上提升了效率。

但是多表連接也有一些缺點。多表連接對表結構的依存度很高，只要表結構出現變更就會同時對資料庫檢索和應用處理兩個部分產生較大影響。另外，多表連接的兼容性不好，資料庫不同SQL文也多少有些差異。而且採用分散資料庫的時候，實現多表連接即麻煩又沒有什麼好處。因此，一些大型系統或者是支持多種類資料庫的系統一般不會使用多表連接，而傾向於採用分解查詢。

這個得看情況，一般數據不大的情況下多表連接查詢和多次單表查詢的效率差不多。如果數據量足夠大，那肯定是多次單表查詢的效率更高。在很多大的公司裡面，都會禁用多表連接查詢，原因就是一旦數據量足夠大的時候多表連接查詢效率會很慢，而且不利於分庫分表的查詢優化。那麼看一下下面這個例子。

兩種查詢方式的比較

我這里有一個資料庫，我們拿裡面的客戶表和地區表做兩種查詢的對比。用戶表數據是31萬條，地區表3511條。

1. 使用連表查詢成都市的客戶總數

2.使用多次單表查詢客戶總數

可以看到，查詢出來的結果都是一樣，但是第一種的連表查詢用了0.67秒中，而第二種多次單表查詢一共用時0.14秒。這個對比已經是很明顯了吧。

雖然這只是一個很簡單的例子，但是對比結果是非常明顯的。在實際應用中可能會更復雜、數據更多，如果還使用連表查詢時非常慢的，而且還消耗伺服器資源。

所以現在在很多大了公司明確要求禁止使用join查詢，比如阿里、騰訊就明確規定禁用三表以上的join查詢。

總結一下，單表查詢的優點

1. 多次單表查詢，讓緩存的效率更高。

許多應用程序可以方便地緩存單表查詢對應的結果對象。另外對於MySQL的查詢緩存來說，如果關聯中的某個表發生了變化，那麼就無法使用查詢緩存了，而拆分後，如果某個表很少改變，那麼基於該表的查詢就可以重復利用查詢緩存結果了。

2. 將查詢分解後，執行單個查詢可以減少鎖的競爭。

3. 在應用層做關聯，更容易對資料庫進行拆分，更容易做到高性能和可擴展。

4. 查詢本身效率也可能會有所提升。

5. 可以減少冗餘記錄的查詢。

6. 在應用中實現了哈希關聯，而不是使用MySQL的嵌套環關聯，某些場景哈希關聯的效率更高很多。

7. 單表查詢有利於後期數據量大了分庫分表，如果聯合查詢的話，一旦分庫，原來的sql都需要改動。

8. 很多大公司明確規定禁用join，因為數據量大的時候查詢確實很慢

所以在數據量不大的情況下，兩種方式的查詢都沒什麼明顯的差別，使用多表連接查詢更方便。但是在數據量足夠大幾十萬、幾百萬甚至上億的數據，或者在一些高並發、高性能的應用中，一般建議使用單表查詢。

如果覺得笨貓的回答對你有用，點個關注，非常感謝。

做java的，在orm框架下，分解查詢是最符合面向對象操作的，挺支持分解查詢的（拙見）

先說結論：不一定。

多表查詢效率低的時候，可以考慮拆解sql成多個小的sql，至於效率是否一定會提高，這個還不一定，具體問題具體問題。當多表查詢效率低的時候，拆解成單個小sql，這只是一個可能的思路，起不起作用，不一定。

sql是一個很復雜的東西，sql引擎會分析執行計劃，並可能按照他認為最優的執行計劃執行sql，但他認為的也不一定是正確的。不同的sql執行計劃不一樣，所以很難斷定sql拆解或者合並的效率。

說了這么多，那到底是多表聯合查詢還是拆解呢？有沒有一個原則？ 有！如果你確定你的單個sql的執行效率比較快，當然可以寫多個單個sql。當然了，具備這個能力需要你對資料庫足夠了解，比如什麼時候走索引，什麼時候nested loop等等。如果你現在的多表聯合查詢比較慢，你需要找出來慢的原因，並分析拆解後的sql的執行計劃，看是否避免了多表聯合查詢的效率問題。

總之吧。這個問題，只能給你一個大體的思路，因為牽扯到很多基礎問題，我覺得最起碼sql執行計劃應該需要了解，一個sql可能的執行計劃有幾十中，復雜sql的執行計劃又是這幾十種的組合。哪種效率低，哪種效率高應該有個大體了解。

多表查詢可以很快，也可以很慢。主要看執行計劃。

單次肯定是多表連接查詢的效率高，但多次單表查詢的吞吐量高，而且容易優化，例如分庫分表，使用緩存減少DB訪問次數等等，所以在大數據量高並發場景通常使用多次單表查詢的方式。另外，不管是單表還是多表連接查詢，SQL的執行時間和數據量、並發量都有很大關系，和掃描的數據行數也很有關系。如果一條SQL，平時執行一次要2秒，10個並發時，系統可能一點問題都沒有，1000個並發時，資料庫可能就被拖死了。我們組之前碰到過好幾次這種問題，一張只有幾萬條數據的表，因為忘記加索引，平時執行只有幾百毫秒，高峰期直接飆到幾十秒，DB差點被拖垮。

單純從效率來講，join的表不太多時，join效率比較高。但是佔用的主要是資料庫伺服器的資源。資料庫資源又是個瓶頸，不易橫向擴展。所以在數據量大的時候，我們會採用單表查詢，把循環和匹配等大量工作移到應用伺服器上。應用伺服器容易擴展，對並發支持更好。

當數據量大到千萬級以上，就建議盡可能減少join，鼓勵使用單表查詢。查詢優化比較容易。這時候使用join的一個大型查詢就可能花很久，對其他查詢造成阻塞，導致服務不可用。

當考慮單表查詢後，就會衍生一系列的策略，比如冷熱數據分離，將熱數據和 歷史 數據分離，大幅降低數據量級以提高熱數據查詢性能，並可以使用內存緩存。這樣又促使你考慮引入微服務架構。

總結，數據量小，查詢並發少，那麼使用join的性能是可控的，開發成本低。當數量級上升到千萬級且不斷增加，盡早考慮向單表查詢切換，否則可能有性能下降會導致系統奔潰。而且性能下降不是線性的，會陡降。

⑤ SQL多表查詢總結

連接查詢包括合並、內連接、外連接和交叉連接，如果涉及多表查詢，了解這些連接的特點很重要。
只有真正了解它們之間的區別，才能正確使用。

UNION 操作符用於合並兩個或多個 SELECT 語句的結果集。

UNION 運算符通過組合其他兩個結果表（例如 TABLE1 和 TABLE2）並消去表中任何重復行而派生出一個結果表。

當 ALL 隨 UNION 一起使用時（即 UNION ALL），不消除重復行。兩種情況下，派生表的每一行不是來自 TABLE1 就是來自 TABLE2。

注意：使用UNION時，兩張表查詢的結果有相同數量的列、列類型相似。

學生表信息（Students）：

教師表信息（Teachers）：

1）基本UNION查詢，查詢學校教師、學生的總的信息表，包括ID和姓名

查詢結果：

2）查詢教師學生全部姓名
因為UNION只會選擇不同的值，如果學生中和教師中有重名的情況，這就需要UNION ALL

查詢結果：

INNER JOIN（內連接），也成為自然連接

作用：根據兩個或多個表中的列之間的關系，從這些表中查詢數據。

注意⚠️: 內連接是從結果中刪除其他被連接表中沒有匹配行的所有行，所以內連接可能會丟失信息。

重點：內連接，只查匹配行。

語法：(INNER可省略)

學生表信息（Students）：

專業信息表（Majors）：

實例：查詢學生信息，包括ID,姓名、專業名稱

查詢結果：

根據結果可以清晰看到，確實只有匹配的行。學生Lucy的信息丟失了。

與內連接相比，即使沒有匹配行，也會返回一個表的全集。

外連接分為三種：左外連接，右外連接，全外連接。
對應SQL：LEFT/RIGHT/FULL OUTER JOIN。
通常我們省略outer 這個關鍵字。寫成：LEFT/RIGHT/FULL JOIN。

重點：至少有一方保留全集，沒有匹配行用NULL代替。

1、LEFT JOIN (左連接)

結果集保留左表的所有行，但只包含第二個表與第一表匹配的行。第二個表相應的空行被放入NULL值。

依然沿用內鏈接的例子:

（1）使用左連接查詢學生的信息，其中包括學生ID，學生姓名和專業名稱。

查詢結果：

通過結果，我們可以看到左連接包含了第一張表的所有信息，在第二張表中如果沒有匹配項，則用NULL代替。

2、RIGHT JOIN (右連接)

右外連接保留了第二個表的所有行，但只包含第一個表與第二個表匹配的行。第一個表相應空行被入NULL值。

右連接與左連接思想類似。只是第二張保留全集，如果第一張表中沒有匹配項，用NULL代替

依然沿用內鏈接的例子，只是改為右連接

（2）使用右連接查詢學生的信息，其中包括學生ID，學生姓名和專業名稱

查詢結果：

通過結果可以看到，包含了第二張表Majors的全集，Computer在Students表中沒有匹配項，就用NULL代替。

3、FULL JOIN (全連接）

會把兩個表所有的行都顯示在結果表中

3)使用全連接查詢學生的信息，其中包括學生ID，學生姓名和專業名稱。

查詢結果：

包含了兩張表的所有記錄，沒有記錄丟失，沒有匹配的行用NULL代替。

4、CROSS JOIN（交叉連接）

交叉連接。交叉連接返回左表中的所有行，左表中的每一行與右表中的所有行組合。交叉連接也稱作笛卡爾積。

簡單查詢兩張表組合，這是求笛卡兒積，效率最低。

笛卡兒積：笛卡爾乘積，也叫直積。假設集合A={a,b}，集合B={0,1,2}，則兩個集合的笛卡爾積為{(a,0),(a,1),(a,2),(b,0),(b,1), (b,2)}。可以擴展到多個集合的情況。類似的例子有，如果A表示某學校學生的集合，B表示該學校所有課程的集合，則A與B的笛卡爾積表示所有可能的選課情況。

4）交叉連接查詢學生的信息，其中包括學生ID，學生姓名和專業名稱。

查詢結果：

5）查詢多表，其實也是笛卡兒積，與CROSS JOIN等價，以下查詢同上述結果一樣。

這個可能很常見，但是大家一定要注意了，這樣就查詢了兩張表中所有組合的全集。

查詢結果：

6）增加查詢條件

注意:在使用CROSS JOIN關鍵字交叉連接表時，因為生成的是兩個表的笛卡爾積，因而不能使用ON關鍵字，只能在WHERE子句中定義搜索條件。

查詢結果：

查詢結果與INNER JOIN一樣，但是其效率就慢很多了。

⑥ 在sql語句多表連接中，in、exists、join哪個效率更高一點

EXISTS、IN與JOIN，都可以用來實現形如「查詢A表中在（或不在）B表中的記錄」的查詢邏輯。x0dx0ax0dx0a在查詢的兩個表大小相當的情況下，3種查詢方式的執行時間通常是：x0dx0aEXISTS <= IN <= JOINx0dx0aNOT EXISTS <= NOT IN <= LEFT JOINx0dx0a只有當表中欄位允許NULL時，NOT IN的方式最慢：x0dx0aNOT EXISTS <= LEFT JOIN <= NOT INx0dx0ax0dx0a但是如果兩個表中一個較小，一個較大，則子查詢表大的用exists，子查詢表小的用in，因為in 是把外表和內表作hash 連接，而exists是對外表作loop循環，每次loop循環再對內表進行查詢。而無論那個表大，用not exists都比not in要快。這是因為如果查詢語句使用了not in 那麼內外表都進行全表掃描，沒有用到索引；而not extsts 的子查詢依然能用到表上的索引。x0dx0ax0dx0aIN的好處是邏輯直觀簡單（通常是獨立子查詢）；缺點是只能判斷單欄位，並且當NOT IN時效率較低，而且NULL會導致不想要的結果。x0dx0aEXISTS的好處是效率高，可以判斷單欄位和組合欄位，並不受NULL的影響；缺點是邏輯稍微復雜（通常是相關子查詢）。x0dx0aJOIN用在這種場合，往往是吃力不討好。JOIN的用途是聯接兩個表，而不是判斷一個表的記錄是否在另一個表。

⑦ sql中多表聯合查詢用什麼方法效率最高

關聯條件最好是主鍵或者有索引的列，然後可以用小表左關聯大表。

⑧ SQL連表查詢跟一個個表查詢那個快各有什麼優點和缺點

SQL鏈接表查詢稱為聯合查詢，表查詢是單個查詢。其區別和優點如下：

1．從發展效率的角度看：

聯合查詢是需要多個單查詢邏輯組合才能完成的查詢工作，聯合查詢只需要一個SQL就可以完成查詢工作，即將業務邏輯轉化為SQL，由資料庫來處理，相對來說，開發效率會更高。

2．從查詢效率來看：

單個查詢具有更好的可重用性，因此比聯合查詢更有效。

當讀取或寫入資料庫時，資料庫使用鎖機制來限制其他連接對其進行操作。由於聯邦查詢比單個查詢慢得多，它們會增加鎖爭用，因此單個查詢更好。

3．從邏輯結構層面來看，分層原則

關聯表示業務規則／邏輯。如果經常使用關聯查詢，就會將大量的業務規則和邏輯放入資料庫中執行，這將大大增加CPU、內存、IO等資源的消耗。

4．從資源利用的角度來看

在大多數情況下，並不是所有相關查詢的結果都得到了有效的使用。例如，後台管理的列表界面會顯示分頁、關聯查詢的結果集，只使用當前頁面的數據，而資料庫需要消耗額外的資源才能得到整個結果集。

5．從架構的可伸縮性的角度來看

大量的相關查詢將導致集中式資料庫體系結構難以轉化為分布式體系結構，可擴展性優化也難以實現。關聯查詢方便快捷，開發效率更高。

不使用關系查詢在體系結構級別上有很多優勢，但是它需要大量的系統分析、設計和開發功能。一般在互聯網行業，如用戶數量最好重視這方面。

由於數據量小，兩個查詢的效率基本沒有差別，但在實際應用中，需要根據數據量、業務復雜度等進行綜合評價。