SQL為什麼不建議執行超過3表以上的多表關聯查詢

概述：前段時間在跟其他公司DBA交流時談到了mysql跟PG之間在多表關聯查詢上的一些區別，相比之下mysql只有一種表連線型別:巢狀迴圈連線(nested-loop),不支援排序-合併連線(sort-merge join)與雜湊連線(hash join)，而PG是都支援的，而且mysql是往簡單化方向去設計的，如果多個表關聯查詢（超過3張表）效率上是比不上PG的。

摘要：

不超過3層是為了效率。更通用 ，更好為了分散式做準備。

下面也對mysql多表關聯這個特性簡單探討下~

MySQL多表關聯查詢效率高點還是多次單表查詢效率高？

A,B兩個表資料規模十幾萬，資料規模都不大，單機MySQL夠用了，在單機的基礎上要關聯兩表的資料，先說一個極端情況，A,B兩個表都沒有索引，並且關聯是笛卡爾積，那關聯結果會爆炸式增長，可能到億級別，這個時候網路IO成了瓶頸，這個時候兩次十萬行結果集的拉去可能遠小於1次億級別的結果集的拉取，那麼將關聯合並拉到service層做更快。

但實際業務中一般不會有這麼蠢的行為，一般關聯會有連線條件，並且連線條件上會有索引，一般是有一個結果集比較小，拿到這個結果集去另一張表去關聯出其它資訊，如果放到service層去做，最快的方式是，先查A表，得到一個小的結果集，一次rpc，再根據結果集，拼湊出B表的查詢條件，去B表查到一個結果集，再一次rpc，再把結果集拉回service層，再一次rpc，然後service層做合併，3次rpc，如果用資料庫的join，關聯結果拉回來，一次rpc，幫你省了兩次rpc，當然資料庫上做關聯更快，對應到資料庫就是一次blk nested loop join，這是業務常用情況。

但是確實大多數業務都會考慮把這種合併操作放到service層，一般是有以下幾方面考慮：

第一：單機資料庫計算資源很貴，資料庫同時要服務寫和讀，都需要消耗CPU，為了能讓資料庫的吞吐變得更高，而業務又不在乎那幾百微妙到毫秒級的延時差距，業務會把更多計算放到service層做，畢竟計算資源很好水平擴充套件，資料庫很難啊，所以大多數業務會把純計算操作放到service層做，而將資料庫當成一種帶事務能力的kv系統來使用，這是一種重業務，輕DB的架構思路

第二：很多複雜的業務可能會由於發展的歷史原因，一般不會只用一種資料庫，一般會在多個資料庫上加一層中介軟體，多個資料庫之間就沒辦法join了，自然業務會抽象出一個service層，降低對資料庫的耦合。

第三：對於一些大型公司由於資料規模龐大，不得不對資料庫進行分庫分表，對於分庫分表的應用，使用join也受到了很多限制，除非業務能夠很好的根據sharding key明確要join的兩個表在同一個物理庫中。而中介軟體一般對跨庫join都支援不好。
舉一個很常見的業務例子，在分庫分表中，要同步更新兩個表，這兩個表位於不同的物理庫中，為了保證資料一致性，一種做法是通過分散式事務中介軟體將兩個更新操作放到一個事務中，但這樣的操作一般要加全域性鎖，效能很捉急，而有些業務能夠容忍短暫的資料不一致，怎麼做？讓它們分別更新唄，但是會存在資料寫失敗的問題，那就起個定時任務，掃描下A表有沒有失敗的行，然後看看B表是不是也沒寫成功，然後對這兩條關聯記錄做訂正，這個時候同樣沒法用join去實現，只能將資料拉到service層應用自己來合併了。。。

到這裡答案就很清楚了~

對關聯查詢進行分解

很多高效能的應用都會對關聯查詢進行分解。

簡單地，可以對每個表進行一次單表查詢，然後將結果在應用程式中進行關聯。例如，下面這個查詢：

select * from tag
join tag_post on tag_post.tag_id=tag.id
join post on tag_post.post_id=post.id
where tag.tag='mysql';

可以分解成下面這些查詢來代替：

Select * from tag where tag='mysql';
Select * from tag_post where tag_id=1234;
Select * from post where id in(123,456,567,9989,8909);

為什麼會這樣做呢？原本一條查詢，這裡卻變成了多條查詢，返回結果又是一模一樣。

事實上，用分解關聯查詢的方式重構查詢具有如下優勢：

讓快取的效率更高。
許多應用程式可以方便地快取單表查詢對應的結果物件。另外對於MySQL的查詢快取來說，如果關聯中的某個表發生了變化，那麼就無法使用查詢快取了，而拆分後，如果某個表很少改變，那麼基於該表的查詢就可以重複利用查詢快取結果了。
將查詢分解後，執行單個查詢可以減少鎖的競爭。
在應用層做關聯，可以更容易對資料庫進行拆分，更容易做到高效能和可延伸。
查詢本身效率也可能會有所提升
可以減少冗餘記錄的查詢。
更進一步，這樣做相當於在應用中實現了雜湊關聯，而不是使用MySQL的巢狀環關聯，某些場景雜湊關聯的效率更高很多。

解釋： RPC(Remote Procedure Call)：遠端過程呼叫，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的思想

到此這篇關於SQL為什麼不建議執行超過3表以上的多表關聯查詢的文章就介紹到這了,更多相關SQL多表關聯查詢內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！