這段時(shí)間在做項(xiàng)目的過(guò)程中，遇到一個(gè)模塊，數(shù)據(jù)之間的聯(lián)系很復(fù)雜，在建表的時(shí)候就很糾結(jié)，到底該怎么去處理這些復(fù)雜的數(shù)據(jù)呢，是單表查詢(xún)，然后在業(yè)務(wù)層去處理數(shù)據(jù)間的關(guān)系，還是直接通過(guò)多表連接查詢(xún)來(lái)處理數(shù)據(jù)關(guān)系呢？

通過(guò)查閱資料和閱讀博客，有以下兩個(gè)回答：

一、《高性能mysql》中的回答

很多高性能的應(yīng)用都會(huì)對(duì)關(guān)聯(lián)查詢(xún)進(jìn)行分解。簡(jiǎn)單地，可以對(duì)每個(gè)表進(jìn)行一次單表查詢(xún)，然后將結(jié)果在應(yīng)用程序中進(jìn)行關(guān)聯(lián)。例如，下面這個(gè)查詢(xú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';

可以分解成下面這些查詢(xún)來(lái)代替：

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

到底為什么要這樣做？

咋一看，這樣做并沒(méi)有什么好處，原本一條查詢(xún)，這里卻變成了多條查詢(xún)，返回結(jié)果又是一模一樣。

事實(shí)上，用分解關(guān)聯(lián)查詢(xún)的方式重構(gòu)查詢(xún)具有如下優(yōu)勢(shì)：（高并發(fā)、高性能的應(yīng)用中，一般建議使用單表查詢(xún)）
1. 讓緩存的效率更高。許多應(yīng)用程序可以方便地緩存單表查詢(xún)對(duì)應(yīng)的結(jié)果對(duì)象。另外對(duì)于MySQL的查詢(xún)緩存來(lái)說(shuō)，如果關(guān)聯(lián)中的某個(gè)表發(fā)生了變化，那么就無(wú)法使用查詢(xún)緩存了，而拆分后，如果某個(gè)表很少改變，那么基于該表的查詢(xún)就可以重復(fù)利用查詢(xún)緩存結(jié)果了。

2. 將查詢(xún)分解后，執(zhí)行單個(gè)查詢(xún)可以減少鎖的競(jìng)爭(zhēng)。

3. 在應(yīng)用層做關(guān)聯(lián)，可以更容易對(duì)數(shù)據(jù)庫(kù)進(jìn)行拆分，更容易做到高性能和可擴(kuò)展。

4. 查詢(xún)本身效率也可能會(huì)有所提升。

5. 可以減少冗余記錄的查詢(xún)。

6. 更進(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)的效率更高很多。

7. 單表查詢(xún)有利于后期數(shù)據(jù)量大了分庫(kù)分表，如果聯(lián)合查詢(xún)的話，一旦分庫(kù)，原來(lái)的sql都需要改動(dòng)。

8. 上次看到某個(gè)CTO技術(shù)分享，公司規(guī)定底層禁止用join聯(lián)合查詢(xún)。數(shù)據(jù)大的時(shí)候確實(shí)慢。

9. 聯(lián)合查詢(xún)或許確實(shí)快，但是mysql的資源通常比程序代碼的資源緊張的多。

二、其他的一些回答

情景假設(shè)：假設(shè)網(wǎng)站有一個(gè)公司庫(kù)版塊，我想搜索某城市的所有公司。

數(shù)據(jù)表：tbl_company （t1）、 tbl_city (t2)。

例1：

t1表中存cityid 根據(jù)id做表連接查詢(xún)

select * from t1 inner join t2 on t1.cityid=t2.cityid;

例2：

t1表中存cityName 用戶(hù)前臺(tái)點(diǎn)擊上海市，則把上海市的id傳到后臺(tái)（不考慮傳cityName），

根據(jù)id查出cityName select cityName from t2 where cityid= #{cityid};

然后 select * from t1 where cityName = #{cityName};

兩者區(qū)別：例1中只做了一次表關(guān)聯(lián)查詢(xún)，例2中分別做了兩次單表查詢(xún)。

考慮到數(shù)據(jù)量大，多表連接查詢(xún)會(huì)影響查詢(xún)效率所以都優(yōu)化為單表查詢(xún)。 TP：以上是在不使用索引的情況下

請(qǐng)問(wèn)哪種效率會(huì)更高些?

答：sql優(yōu)化與業(yè)務(wù)也有關(guān)系，這條語(yǔ)句的查詢(xún)會(huì)不會(huì)頻繁，要不要考慮2次連接帶來(lái)的開(kāi)銷(xiāo)，如果這些都不用考慮的話，都沒(méi)有索引的情況下，感覺(jué)相差不大，2應(yīng)該略?xún)?yōu)于1。

數(shù)據(jù)沒(méi)有特別大的情況還是級(jí)聯(lián)查詢(xún)快。

對(duì)于傳統(tǒng)的數(shù)據(jù)庫(kù)涉及來(lái)說(shuō), 盡可能減少數(shù)據(jù)庫(kù)查詢(xún)次數(shù).

BUT, 1. mysql都對(duì)處理連接/斷開(kāi)連接, 回復(fù)小而簡(jiǎn)單的 查詢(xún)是非常快的; 2.現(xiàn)在的網(wǎng)絡(luò)已經(jīng)非?？炝? 所以多個(gè)小的查詢(xún)對(duì)mysql來(lái)說(shuō)可能更快一些.

最后, 大神也沒(méi)有結(jié)論哪個(gè)更好. 呵呵, 其實(shí)整本書(shū)都明確表達(dá)一個(gè)意思, 測(cè)試測(cè)試! 做benchmark! 對(duì)于自己的數(shù)據(jù)環(huán)境, 把兩種方式都測(cè)試一下. 用數(shù)據(jù)說(shuō)話.

三、總結(jié)

個(gè)人建議還是用單表查詢(xún)！在應(yīng)用層做數(shù)據(jù)之間的關(guān)聯(lián)會(huì)更好！

以上就是MySql單表查詢(xún)與多表連接查詢(xún)效率問(wèn)題的詳細(xì)內(nèi)容，更多關(guān)于MySql單表與多表連接查詢(xún)效率的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論