問題描述

最近看高性能ＭySQl，里面是推薦把聯(lián)合查詢分解為多個(gè)簡(jiǎn)單的查詢，既然是這樣 那么還要聯(lián)合查詢干嘛？究竟是如何選擇才是效率更高的選擇呢？

問題解答

簡(jiǎn)單的聯(lián)合查詢一般沒有必要分解，這里所說的應(yīng)該是比較復(fù)雜的聯(lián)合查詢，譬如聯(lián)合查詢3，4張表，如果查詢較為復(fù)雜，涉及到分組，排序什么的，在運(yùn)行時(shí)不能有效利用索引的。甚至有可能產(chǎn)生臨時(shí)表。那效率就會(huì)比較差。而且不利于查詢緩存。分解后針對(duì)每個(gè)簡(jiǎn)單的查詢，數(shù)據(jù)庫有查詢緩存機(jī)制，會(huì)更加高效。對(duì)聯(lián)合查詢的語句盡量用explain分析一下有哪些問題？針對(duì)性的去改正。該分解的時(shí)候還是要分解。

select * from tb1left join tb2 on tb1.id=tb2.tidwhere tb1.stat=1 and tb2.stat=1 and tb1.type=1

select * from (select * from tb1 where stat=1 and type=1) as tb1left join tb2 on tb1.id=tb2.tidwhere tb2.stat=1

上面是一個(gè)簡(jiǎn)單的案例, 其實(shí)我不是太明白你說的聯(lián)合查詢分解成多個(gè)簡(jiǎn)單的查詢, 上面只能是我個(gè)人的一些優(yōu)化(分解)方案而已(雖然也并不是每次都是這么用).

如果你所說的分解是將聯(lián)表拆成很多個(gè)語句, 然后在代碼中依次進(jìn)行調(diào)用的話, 相信效率反而比聯(lián)表還低, 每次連接數(shù)據(jù)庫的 IO 開銷肯定比一次聯(lián)表來的多.

優(yōu)化聯(lián)表查詢效率用一句話來說就是 用最少的正確數(shù)據(jù)進(jìn)行關(guān)聯(lián)

最少的數(shù)據(jù), 就可以通過, 在表進(jìn)行關(guān)聯(lián)前, 提前將正確的數(shù)據(jù)提取出來, 避免關(guān)聯(lián)時(shí)還有很多明顯已經(jīng)知道是錯(cuò)誤的數(shù)據(jù)再去關(guān)聯(lián).

無論是何種 join 方式, 這種方式都能適用.

更多的提高效率方案也還有很多像是 where 的順序, 字段類型, 索引 等等, 這個(gè)范圍就很大了.

只要用好索引，聯(lián)合查詢沒什么問題