MySQL多表關聯查詢效率高點還是多次單錶查詢效率高，為什麼？

1樓：趙衍

網際網路場景的話，就算join能巧妙的優化到比多次單錶快，我也會選擇多次單錶，保險。就像事務一樣，大事務往往帶來不穩定的因素，最好細粒度的拆分成小事務去處理。

2樓：

大量關聯查詢的時候就是吃屎的效能。。所以還是單錶查詢吧。之前乙個5w行的資料，關聯5個表左右，乙個比較複雜的sql，查詢40秒以上算快的情況，還是乙個不會寫程式專門做資料庫的寫的

3樓：畫風景

看具體場景吧，都不是絕對的。

舉個極端的場景，如果mysql本身壓力很高，這個時候你的應用就適合在service合併資料；如果mysql壓力不高，在sql中合併也不錯。

當然這只是一種情況，還是那句話，看具體場景

4樓：徐志斌

從內連線的角度來講，資料庫通常會實現2種執行計畫。第一種是NESTED LOOP。這種執行計畫通常用於小表關聯，能夠最大限度的減少記憶體開銷並盡快返回結果。

第二種是HASH。這種執行計畫通常用於小表和大表關聯，或者大表和大表關聯，會有一些記憶體開銷，但是大資料量下的處理速度是NESTED LOOP不可比擬的。如果2張表都是十幾萬條記錄的話，資料庫的查詢優化器應該會選擇HASH JOIN來實現內連線操作。

而如果關聯操作放在應用裡做，幾乎所有程式設計師都會選擇2重迴圈去實現，這種邏輯是被HASH JOIN完爆的。

還有就是放在應用層做還有很大的網路開銷，主要是資料庫伺服器和應用伺服器之間的開銷。顯然，從網路開銷的角度來說，也應該把內連線放在資料庫上實現。

5樓：今天也要加油鴨

關聯帶分頁

關聯查詢，索引建好，每次查詢外面套分頁，寫得好的話響應速度應該都不會到毫秒吧

震驚！慢SQL居然能優化到這種速度，我不服！

@阿里云云棲社群

6樓：樵夫

補充一下，使用join未必效率全低，曾遇到的乙個慢sql調優，為方便簡單寫：步驟一，

select tableA.id as ids from tableA where age>20;

select tableB.score from tableB where id in (ids);

這是乙個很常見的查詢，步驟一和步驟二，相當於

select tableB.score from tableB inner join tableA on tableA.id=tableB.id;

這個效率誰高，看具體情況了。最後測試結果是inner join的效率高。

為什麼網際網路公司不讓使用join？

第一，不利於寫操作。執行讀操作時，會鎖住被讀的資料，阻塞其他業務對該部分資料的更新操作(U or D)。如果涉及多個聚合函式（快取中沒有max or min時），相當於同時鎖住多張表，不能進行讀寫，直接影響其他業務，這影響了系統的整體效能；

第二，不利於維護。業務發生變動時，比如join中一張表改了，可能導致系統中原有的sql不可用，最終導致基於該SQL執行結果的上層顯示失敗（也意味著以往的開發工作已無效）。

如果使用步驟一和步驟二的方式，只需要修改其中乙個步驟就行。實際工作中，也就是只需要修改其中的乙個service（對應一張表）即可。

既影響效能，又不利於維護，所以我們盡量不要用join。另外，集團不讓用三張表，是在OLTP場景中。不要一葉障目哦，如果是在OLAP的應用場景中，使用join是非常合適的。