單表查詢和多表鏈接查詢哪一個效率更快

一.第一個解答來源於《高性能Mysql》中的回答

不少高性能的應用都會對關聯查詢進行分解。簡單地，能夠對每一個表進行一次單表查詢，而後將結果在應用程序中進行關聯。例如，下面這個查詢：

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

到底爲何要這樣作？

咋一看，這樣作並無什麼好處，本來一條查詢，這裏卻變成了多條查詢，返回結果又是如出一轍。

事實上，用分解關聯查詢的方式重構查詢具備以下優點：（高併發、高性能的應用中，通常建議使用單表查詢）

1. 讓緩存的效率更高。

許多應用程序能夠方便地緩存單表查詢對應的結果對象。另外對於MySQL的查詢緩存來講，若是關聯中的某個表發生了變化，那麼就沒法使用查詢緩存了，而拆分後，若是某個表不多改變，那麼基於該表的查詢就能夠重複利用查詢緩存結果了。

2. 將查詢分解後，執行單個查詢能夠減小鎖的競爭。

3. 在應用層作關聯，能夠更容易對數據庫進行拆分，更容易作到高性能和可擴展。

4. 查詢自己效率也可能會有所提高。

5. 能夠減小冗餘記錄的查詢。

6. 更進一步，這樣作至關於在應用中實現了哈希關聯，而不是使用MySQL的嵌套環關聯，某些場景哈希關聯的效率更高不少。

7. 單表查詢有利於後期數據量大了分庫分表，若是聯合查詢的話，一旦分庫，原來的sql都須要改動。

8. 上次看到某個CTO技術分享，公司規定底層禁止用join聯合查詢。數據大的時候確實慢。

9. 聯合查詢或許確實快，可是mysql的資源一般比程序代碼的資源緊張的多。

二.其餘回答

情景假設：假設網站有一個公司庫版塊，我想搜索某城市的全部公司。

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

例1： t1表中存cityid  根據id作錶鏈接查詢   select * from t1 inner join t2 on t1.cityid=t2.cityid;

例2： t1表中存cityName 用戶前臺點擊上海市，則把上海市的id傳到後臺（不考慮傳cityName），根據id查出cityName           select cityName from t2 where cityid= #{cityid};，   而後 select * from t1 where cityName = #{cityName};

二者區別：例1中只作了一次表關聯查詢，例2中分別作了兩次單表查詢。 

考慮到數據量大，多表鏈接查詢會影響查詢效率因此都優化爲單表查詢。 TP：以上是在不使用索引的狀況下

請問哪一種效率會更高些?

答：sql優化與業務也有關係，這條語句的查詢會不會頻繁，要不要考慮2次鏈接帶來的開銷，若是這些都不用考慮的話，都沒有索引的狀況下，感受相差不大，2應該略優於1。

數據沒有特別大的狀況仍是級聯查詢快。

對於傳統的數據庫涉及來講, 儘量減小數據庫查詢次數.

BUT, 1. mysql都對處理鏈接/斷開鏈接, 回覆小而簡單的 查詢是很是快的; 2.如今的網絡已經很是快了. 因此多個小的查詢對mysql來講可能更快一些.

最後, 大神也沒有結論哪一個更好. 呵呵, 其實整本書都明確表達一個意思, 測試測試! 作benchmark! 對於本身的數據環境, 把兩種方式都測試一下. 用數聽說話.

總結：建議仍是用單表查詢！