目錄

• 一、概述
• 二、討論

---

一、概述

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

下面也對 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 的嵌套環關聯，某些場景哈希關聯的效率更高很多。

---

轉載于：https://www.cnblogs.com/Java-no-1/p/11019615.html

總結

以上是生活随笔為你收集整理的为什么 MySQL 不建议执行超过 3 表以上的多表关联查询？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。