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

在數(shù)據(jù)量不夠大的時候，用join沒有問題，但是一般都會拉到service層上去做

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

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

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

舉一個很常見的業(yè)務(wù)例子，在分庫分表中，要同步更新兩個表，這兩個表位于不同的物理庫中，為了保證數(shù)據(jù)一致性，一種做法是通過分布式事務(wù)中間件將兩個更新操作放到一個事務(wù)中，但這樣的操作一般要加全局鎖，性能很捉急，而有些業(yè)務(wù)能夠容忍短暫的數(shù)據(jù)不一致，怎么做？讓它們分別更新唄，但是會存在數(shù)據(jù)寫失敗的問題，那就起個定時任務(wù)，掃描下A表有沒有失敗的行，然后看看B表是不是也沒寫成功，然后對這兩條關(guān)聯(lián)記錄做訂正，這個時候同樣沒法用join去實現(xiàn)，只能將數(shù)據(jù)拉到service層應(yīng)用自己來合并了。。。

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

讓緩存的效率更高。
許多應(yīng)用程序可以方便地緩存單表查詢對應(yīng)的結(jié)果對象。另外對于MySQL的查詢緩存來說，如果關(guān)聯(lián)中的某個表發(fā)生了變化，那么就無法使用查詢緩存了，而拆分后，如果某個表很少改變，那么基于該表的查詢就可以重復(fù)利用查詢緩存結(jié)果了。
將查詢分解后，執(zhí)行單個查詢可以減少鎖的競爭。
在應(yīng)用層做關(guān)聯(lián)，可以更容易對數(shù)據(jù)庫進行拆分，更容易做到高性能和可擴展。
查詢本身效率也可能會有所提升
可以減少冗余記錄的查詢。
更進一步，這樣做相當于在應(yīng)用中實現(xiàn)了哈希關(guān)聯(lián)，而不是使用MySQL的嵌套環(huán)關(guān)聯(lián)，某些場景哈希關(guān)聯(lián)的效率更高很多。

總結(jié)

以上是生活随笔為你收集整理的mysql的join查询和多次查询比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。