點選「 IT碼徒 」， 關註，置頂 公眾號

每日技術幹貨，第一時間送達！

1

概述

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

2

摘要

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

3

多表關聯

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 whereidin(123,456,567,9989,8909);

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

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

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

— END —

PS：防止找不到本篇文章，可以收藏點贊，方便翻閱尋找哦。

往期推薦