為什么阿里巴巴規(guī)定禁止超過三張表 join？

前段時間在跟其他公司DBA交流時談到了mysql跟PG之間在多表關聯(lián)查詢上的一些區(qū)別，相比之下mysql只有一種表連接類型:嵌套循環(huán)連接(nested-loop)，不支持排序-合并連接(sort-merge join)與散列連接(hash join)，而PG是都支持的，而且mysql是往簡單化方向去設計的，如果多個表關聯(lián)查詢（超過3張表）效率上是比不上PG的。

• 不超過3層是為了效率。

• 更通用 ，更好為了分布式做準備。

下面也對mysql多表關聯(lián)這個特性簡單探討下~

MySQL多表關聯(lián)查詢效率高點還是多次單表查詢效率高？

A,B兩個表數(shù)據(jù)規(guī)模十幾萬，數(shù)據(jù)規(guī)模都不大，單機MySQL夠用了，在單機的基礎上要關聯(lián)兩表的數(shù)據(jù)，先說一個極端情況，A,B兩個表都沒有索引，并且關聯(lián)是笛卡爾積，那關聯(lián)結果會爆炸式增長，可能到億級別，這個時候網絡IO成了瓶頸，這個時候兩次十萬行結果集的拉去可能遠小于1次億級別的結果集的拉取，那么將關聯(lián)合并拉到service層做更快。

但實際業(yè)務中一般不會有這么蠢的行為，一般關聯(lián)會有連接條件，并且連接條件上會有索引，一般是有一個結果集比較小，拿到這個結果集去另一張表去關聯(lián)出其它信息。

如果放到service層去做，最快的方式是，先查A表，得到一個小的結果集，一次rpc，再根據(jù)結果集，拼湊出B表的查詢條件，去B表查到一個結果集，再一次rpc，再把結果集拉回service層，再一次rpc，然后service層做合并，3次rpc。

如果用數(shù)據(jù)庫的join，關聯(lián)結果拉回來，一次rpc，幫你省了兩次rpc，當然數(shù)據(jù)庫上做關聯(lián)更快，對應到數(shù)據(jù)庫就是一次blk nested loop join，這是業(yè)務常用情況。

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

第一

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

第二

很多復雜的業(yè)務可能會由于發(fā)展的歷史原因，一般不會只用一種數(shù)據(jù)庫，一般會在多個數(shù)據(jù)庫上加一層中間件，多個數(shù)據(jù)庫之間就沒辦法join了，自然業(yè)務會抽象出一個service層，降低對數(shù)據(jù)庫的耦合。

第三

對于一些大型公司由于數(shù)據(jù)規(guī)模龐大，不得不對數(shù)據(jù)庫進行分庫分表，對于分庫分表的應用，使用join也受到了很多限制，除非業(yè)務能夠很好的根據(jù)sharding key明確要join的兩個表在同一個物理庫中。而中間件一般對跨庫join都支持不好。

舉一個很常見的業(yè)務例子，在分庫分表中，要同步更新兩個表，這兩個表位于不同的物理庫中，為了保證數(shù)據(jù)一致性，一種做法是通過分布式事務中間件將兩個更新操作放到一個事務中，但這樣的操作一般要加全局鎖，性能很捉急，而有些業(yè)務能夠容忍短暫的數(shù)據(jù)不一致，怎么做？

讓它們分別更新唄，但是會存在數(shù)據(jù)寫失敗的問題，那就起個定時任務，掃描下A表有沒有失敗的行，然后看看B表是不是也沒寫成功，然后對這兩條關聯(lián)記錄做訂正，這個時候同樣沒法用join去實現(xiàn)，只能將數(shù)據(jù)拉到service層應用自己來合并了。

到這里答案就很清楚了~

對關聯(lián)查詢進行分解

很多高性能的應用都會對關聯(lián)查詢進行分解。

簡單地，可以對每個表進行一次單表查詢，然后將結果在應用程序中進行關聯(lián)。例如，下面這個查詢：

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);

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

事實上，用分解關聯(lián)查詢的方式重構查詢具有如下優(yōu)勢：

• 讓緩存的效率更高。

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

• 將查詢分解后，執(zhí)行單個查詢可以減少鎖的競爭。

• 在應用層做關聯(lián)，可以更容易對數(shù)據(jù)庫進行拆分，更容易做到高性能和可擴展。

• 查詢本身效率也可能會有所提升

• 可以減少冗余記錄的查詢。

• 更進一步，這樣做相當于在應用中實現(xiàn)了哈希關聯(lián)，而不是使用MySQL的嵌套環(huán)關聯(lián)，某些場景哈希關聯(lián)的效率更高很多。

RPC(Remote Procedure Call)：遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的思想

來源：blog.csdn.net/NumberOneStudent/article/details/102776289

最近熬夜給大家準備了非常全的一套Java一線大廠面試題。全面覆蓋BATJ等一線互聯(lián)網公司的面試題及解答，由BAT一線互聯(lián)網公司大牛帶你深度剖析面試題背后的原理，不僅授你以魚，更授你以漁，為你面試掃除一切障礙。


資源，怎么領??？

掃二維碼，加我微信，備注：面試題

一定要備注：面試題，不要急哦，工作忙完后就會通過！