mysql的join查询和多次查询比较
MySQL多表關(guān)聯(lián)查詢效率高點(diǎn)還是多次單表查詢效率高?
在數(shù)據(jù)量不夠大的時(shí)候,用join沒(méi)有問(wèn)題,但是一般都會(huì)拉到service層上去做
第一:單機(jī)數(shù)據(jù)庫(kù)計(jì)算資源很貴,數(shù)據(jù)庫(kù)同時(shí)要服務(wù)寫和讀,都需要消耗CPU,為了能讓數(shù)據(jù)庫(kù)的吞吐變得更高,而業(yè)務(wù)又不在乎那幾百微妙到毫秒級(jí)的延時(shí)差距,業(yè)務(wù)會(huì)把更多計(jì)算放到service層做,畢竟計(jì)算資源很好水平擴(kuò)展,數(shù)據(jù)庫(kù)很難啊,所以大多數(shù)業(yè)務(wù)會(huì)把純計(jì)算操作放到service層做,而將數(shù)據(jù)庫(kù)當(dāng)成一種帶事務(wù)能力的kv系統(tǒng)來(lái)使用,這是一種重業(yè)務(wù),輕DB的架構(gòu)思路
第二:很多復(fù)雜的業(yè)務(wù)可能會(huì)由于發(fā)展的歷史原因,一般不會(huì)只用一種數(shù)據(jù)庫(kù),一般會(huì)在多個(gè)數(shù)據(jù)庫(kù)上加一層中間件,多個(gè)數(shù)據(jù)庫(kù)之間就沒(méi)辦法join了,自然業(yè)務(wù)會(huì)抽象出一個(gè)service層,降低對(duì)數(shù)據(jù)庫(kù)的耦合。
第三:對(duì)于一些大型公司由于數(shù)據(jù)規(guī)模龐大,不得不對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表,對(duì)于分庫(kù)分表的應(yīng)用,使用join也受到了很多限制,除非業(yè)務(wù)能夠很好的根據(jù)sharding key明確要join的兩個(gè)表在同一個(gè)物理庫(kù)中。而中間件一般對(duì)跨庫(kù)join都支持不好。
舉一個(gè)很常見的業(yè)務(wù)例子,在分庫(kù)分表中,要同步更新兩個(gè)表,這兩個(gè)表位于不同的物理庫(kù)中,為了保證數(shù)據(jù)一致性,一種做法是通過(guò)分布式事務(wù)中間件將兩個(gè)更新操作放到一個(gè)事務(wù)中,但這樣的操作一般要加全局鎖,性能很捉急,而有些業(yè)務(wù)能夠容忍短暫的數(shù)據(jù)不一致,怎么做?讓它們分別更新唄,但是會(huì)存在數(shù)據(jù)寫失敗的問(wèn)題,那就起個(gè)定時(shí)任務(wù),掃描下A表有沒(méi)有失敗的行,然后看看B表是不是也沒(méi)寫成功,然后對(duì)這兩條關(guān)聯(lián)記錄做訂正,這個(gè)時(shí)候同樣沒(méi)法用join去實(shí)現(xiàn),只能將數(shù)據(jù)拉到service層應(yīng)用自己來(lái)合并了。。。
事實(shí)上,用分解關(guān)聯(lián)查詢的方式重構(gòu)查詢具有如下優(yōu)勢(shì):
讓緩存的效率更高。
許多應(yīng)用程序可以方便地緩存單表查詢對(duì)應(yīng)的結(jié)果對(duì)象。另外對(duì)于MySQL的查詢緩存來(lái)說(shuō),如果關(guān)聯(lián)中的某個(gè)表發(fā)生了變化,那么就無(wú)法使用查詢緩存了,而拆分后,如果某個(gè)表很少改變,那么基于該表的查詢就可以重復(fù)利用查詢緩存結(jié)果了。
將查詢分解后,執(zhí)行單個(gè)查詢可以減少鎖的競(jìng)爭(zhēng)。
在應(yīng)用層做關(guān)聯(lián),可以更容易對(duì)數(shù)據(jù)庫(kù)進(jìn)行拆分,更容易做到高性能和可擴(kuò)展。
查詢本身效率也可能會(huì)有所提升
可以減少冗余記錄的查詢。
更進(jìn)一步,這樣做相當(dāng)于在應(yīng)用中實(shí)現(xiàn)了哈希關(guān)聯(lián),而不是使用MySQL的嵌套環(huán)關(guān)聯(lián),某些場(chǎng)景哈希關(guān)聯(lián)的效率更高很多。
總結(jié)
以上是生活随笔為你收集整理的mysql的join查询和多次查询比较的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 利用java做前端连接数据库_基于jav
- 下一篇: win7 iis php mysql_w